Cmdlet Extension Agent dla Exchange 2013 – modyfikacja ustawień skrzynki pocztowej

Jedną z ciekawych i ciągle mało znanych funkcjonalności w Exchange 2013 (chociaż pojawiła się już w Exchange 2010) jest możliwość wykorzystania agenta skryptowego do realizowania dodatkowych akcji po wykonaniu standardowego cmdleta Exchange. Przykładem może być operacja tworzenia skrzynki Exchange – enable-mailbox lub new-mailbox nie posiadają opcji pozwalających np. na ustawienie domyślnego języka i strefy czasowej. Przypomniał o tym ostatnio Tony Redmond na swoim blogu. Podobnie w przypadku włączenia funkcjonalności SingleItemRecovery lub audytowania musimy wykonać dodatkowe operacje. Automatyzację konfiguracji tych parametrów umożliwia nam dodatek Cmdlet Extension Agents, a tak naprawdę to jeden z 8 agentów – Scripting Agent:

Jak możemy go użyć?

W katalogu instalacyjnym Exchange, w podkatalogu Bin\CmdletExtensionAgent znajdują się niezbędne rozszerzenia oraz przykład pliku konfiguracyjnego jak widać na poniższym rysunku:

Tworząc plik konfiguracyjny (obowiązkowa nazwa ScriptingAgentConfig.xml)definiujemy w nim, dla jakich komend wykonywane są dodatkowe operacje i jakie są warunki początkowe. W przypadku uzupełnienia operacji tworzenia skrzynki w pliku xml dodajemy sekcję dla odpowiednich komend i uzależniamy wykonanie sekwencji dodatkowych czynności od poprawności wykonania komendy podstawowej (weryfikując rezultat zwrócony przez metodę “OnComplete”). Oczywiście możemy dodać więcej operacji. Poniższy plik opisuje operację ustawienia polskiej wersji językowej, godziny rozpoczęcia pracy w firmie, polskiej strefy czasowej. Włączone zostaje również SingleItemRecovery oraz audytowanie operacji na skrzynce (tylko administrator i delegaci, żeby włączyć audytowanie dla właściciela należy dodatkowo zdefiniować, jakie operacje są rejestrowane).

<?xml version="1.0" encoding="utf-8" ?>
<Configuration version="1.0">
    <Feature Name="Mailboxes" Cmdlets="New-Mailbox, Enable-Mailbox">
        <ApiCall Name="OnComplete">
        if($succeeded) {
            $Name= $ProvisioningHandler.UserSpecifiedParameters["Name"]
            Set-Mailbox $Name -Languages "pl-PL"
            Set-MailboxRegionalConfiguration $Name -DateFormat "yyyy-MM-dd" -TimeZone "Central European Standard Time"
            Set-MailboxCalendarConfiguration $Name -WorkingHoursStartTime "09:00:00"
            Set-Mailbox $Name -SingleItemRecoveryEnabled $true
            Set-Mailbox $Name -AuditEnabled $true
        }
        </ApiCall>
    </Feature>
</Configuration>

Plik musi znajdować się na wszystkich serwerach z rolą Mailbox. W ten sposób, jeżeli nie popełniliśmy błędu dla każdej nowo tworzonej skrzynki, zostaną ustawione parametry pokazane powyżej, niezależnie czy będzie ona tworzona z poziomu Exchange Management Shella czy konsoli webowej.

Oczywiście musimy najpierw włączyć agenta komendą:

Enable-CmdletExtensionAgent “Scripting Agent”

Zmiany w certyfikatach publicznych

Kiedy Microsoft ogłosił w drugiej połowie zeszłego roku koniec wsparcia dla certyfikatów wykorzystujących SHA-1 z dniem 1.01.2017, wydawało się to terminem odległym. Jednak Google już od listopada 2014 zaktualizował przeglądarkę Chrome, tak żeby wyświetlała ostrzeżenia dla certyfikatów z SHA-1, wygasających w 2017 roku i stopniowo takie obostrzenia będą się powiększać. Co zatem należy zrobić? Przejść na certyfikaty wykorzystujące SHA-2 (przeważnie jest to SHA-256). Na pozór nic prostszego. Jednak odnowienie certyfikatów do Exchange u kilku klientów w ostatnich dniach pokazało mi, że dostawcy już taką zmianę realizują – nowe certyfikaty, m. in GoDaddy czy też RapidSSL przychodzą ze zmodyfikowaną wersją algorytmów. Co ciekawe, w przypadku zaleceń dla serwerów Exchange zarówno kreator jak i cmdlet generujący nowy wniosek o certyfikat używają domyślnie (i nie ma możliwości tego zmienić) SHA-1. Mam nadzieję, że zespół Exchange wkrótce się obudzi i zostanie to poprawione w kolejnych wersjach (w tym kwartale powinien być dostępny kolejny Cummulative Update). Jak na razie rozwiązanie jest proste, chociaż nie tak oczywiste.

Mając stary certyfikat podpisany SHA-1, dostajemy po wniesieniu opłaty nowy certyfikat wygenerowany przez dostawcę, zgodnie z danymi firmy. Jednak jego standardowy import na serwer z poziomu narzędzi Exchange lub konsoli IIS nie podłącza go do klucza prywatnego.

Stosujemy zatem obejście opisane w artykule bazie wiedzy Microsoft KB889651 lub na serwisach dostawców certyfikatów.

Czyli po sprawdzeniu numeru seryjnego certyfikatu wykonujemy komendę:

certutil –repairstore my <serial number>

Certyfikat został podpięty do klucza prywatnego, teraz możemy podłączyć usługi Exchange, Lynca czy dowolne inne.

Co nam przyniesie rok 2015?

Jakoś tak jest, że na przełomie roku wypada zrobić krótkie podsumowanie. Rok 2014 minął nie wiadomo kiedy, w nawale pracy nawet nie bardzo miałem czas w ostatnich dwóch miesiącach publikować jakieś artykuły – kilka z nich czeka na dokończenie i publikację – mam nadzieję, że nadrobię to przy okazji urlopu. Na bieżąco starałem się publikować krótkie wpisy na Twitterze, co zaowocowało wzrostem ilości tzw. Followerów (do 350). Mimo wszystko jednak wydaje mi się, że był to rok udany, patrząc na statystyki odwiedzin bloga, wyglądało to całkiem interesująco, ze średnią miesięczną ponad 2000 odwiedzin:

Co nam przyniesie rok 2015? Zmiany na pewno będą duże – Windows 10 powoli zaczyna nabierać kształtów, w tym roku również pojawi się nowa rodzina produktów Office. Na razie informacje są NDA, ale jak tylko można będzie udostępnić informacje na temat Office 16, Skype for Bussiness lub Exchange 16 (do których wersji Beta mam dostęp) na pewno się nimi podzielę. Podobnie jak doświadczeniami z kolejnych ciekawych projektów.