K-NET s.c.

Microsoft Exchange – kopia zapasowa skrzynki w formacie MSG

Wykonywanie kopii zapasowych serwera Microsoft Exchange 2010 jest zagadnieniem dobrze znanym, szeroko opisywanym i wydawać by się mogło, że nie można już nic więcej zaproponować w tej dziedzinie. Jeśli jednak nie mamy uprawnień administratora serwera, dysponujemy tylko klientem Outlook a chielibyśmy robić regularnie kopie swojej skrzynki to, jak się okazuje, oferta aplikacji jest dość skromna. Mowa tu, rzecz jasna, o sytuacji gdy nie dysponujemy lokalna kopią PST a korzystamy wyłącznie zdalnie z zasobów sieciowych (de facto oznacza to korzystanie z pliku OST – kopii offline). Można zawsze robić ręcznie kopie korzystając z funkcji eksport do pliku PST lub nieco zautmatyzować proces korzystając np. z AutoIt. Jest to jednak trudne ze względu na niestandardowy interfejs Outlooka.

Stojąc przed opisywanym problemem założyłem, że chciałbym wykorzystać harmonogram zadań systemowych oraz tekstowy skrypt wsadowy BAT lub CMD (do tego niekoniecznie wykorzystujący np. PowerShell). Czyli coś co wydawać by się mogło nierealne. A jednak nie do końca.

Poszukując aplikacji, która spełniałaby założenia trafiłem na ReliefJet Essentials for Outlook. Czemu jest ona wyjątkowa? Ponieważ oprócz interfejsu graficznego posiada tryb pracy wsadowej. Co więcej, najpierw można przygotować np. kopie zapasowe korzystając z okienek konfiguracyjnych a potem skorzystać z ikonki Show command line, żeby zobaczyć jak będzie wyglądać odpowiednia komenda systemowa.

ExecutorCli.exe /u OutlookFolderBackup ↵
Profile=nazwa_konta For="\\nazwa_skrzynki*" ↵ 
IgnoreErrors=True TargetDir=C:\TEMP\ ↵
StartDate="2015-01-01 00:00:00.000" ↵
Report=C:\TEMP\raport.csv

Powyższa komenda umożliwia przygotowanie kopii skrzynki współdzielonej przy użyciu wybranego profilu Outlooka. Możemy ponadto określić od jakiej daty zostanie ona wykonana oraz przygotować raport końcowy.

Możliwości aplikacji są dużo większe i myślę, że naprawde warto zapoznać się z tym produktem.

MG

Tryb on line w Outlook 2010 dla udostępnionych skrzynek

Udostępnianie skrzynek pocztowych za pomocą serwera MS Exchange jest jedną z najczęściej wykorzystywanych funkcji. Umożliwia wygodny wgląd w zawartość czyjejś poczty np. podczas zastępstwa lub nieobecności. W kliencie MS Outlook 2010 skrzynka udostępniana pojawia się na liście zasobów wystarczy zatem wybrać ją aby wyświetlić zawartość. W tym momencie mogą pojawić się problemy z synchronizacją. Outlook 2010 domyślnie bufforuje (tryb cache) zawartość dołączanych skrzynek co oznacza, że będzie starał się pobrać ich zawartość na dysk lokalny. Nietrudno jest sobie wyobrazić, że przy skrzynce dużych rozmiarów oraz niewydajnym łączu proces taki może trwać niemal bez końca. W poprzednich wersjach Outlooka domyślnym trybem działania był tryb bez buforowania (on line). Na szczęście istnieją sposoby za pomocą, których można przyrócić tą funkcję. Jednym z najszybszych jest zmodyfikowanie rejestru systemowego:

• Zamykamy Outlook.
• Z menu start uruchamiamy edytor rejestru: regdit.exe.
• Wyszukujemy i wybieramy następujący klucz:
  HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Cached Mode
  jeśli nie ma klucza Cached Mode to należy go utworzyć.
• W menu Edytuj wskazujemy opcje Nowy i wybieramy wartość DWORD.
• Podajemy nazwę CacheOthersMail i zatwierdzamy wciskając ENTER.
• Z menu Edytuj wybieramy opcję Modyfikuj i wpisujemy wartość 0.
• Zamykamy edytor rejestru.
• Uruchamiamy Outlook.

Od tego momentu wszystkie udostępnione szkrzynki pocztowe będą działać w trybie on line. Trzeba jednak pamiętać, że oznacza to, że aby przejrzeć ich zawartość konieczne jest połączenie z serwerem MS Exchange. Cóż, coś za coś.

MG

Plik wsadowy ze skryptem PowerShell dla serwera MS Exchange

PowerShell to rozbudowane, konsolowe narzędzie do administracji systemem operacyjnym Windows Server. Długie polecenia, ilość opcji a także niezrozumiałe, na pierwszy rzut oka, przełączniki powodują, że rozwiązanie to może zniechęcić. Tym bardziej, jeśli ktoś jest amatorem tzw. ‘wyklikiwania’ poleceń. Niemniej jest to najlepsza, o ile nie jedyna, droga do pisania skryptów systemowych, które można dodać do schedulera systemowego i tym samym załatwić sobie dużo wolnego czasu.

Standardowo PowerShell wykorzystywany jest do czynności ogólno-systemowych. Jednak instalując nowe usługi na swoim serwerze np. Microsoft Exchange Server, otrzymujemy dostęp do zmodyfikowanego pod kątem Exchange środowiska PowerShell, która umożliwia zarządzanie. Czy można zatem przygotować skrypt, który będzie wykonywany w tle i będzie korzystał z komend właściwych dla wspomnianego środowiska? Można i należy to robić, szczególnie w przypadku takich zadań jak chociażby raportowanie zdarzeń itp.

Zamieszczony poniżej przykład pokazuje jak powinien wyglądać plik wsadowy (może być to popularny batch), który wywoła środowisko PowerShell dla MS Exchange a następnie przygotuje raport w pliku, zawierający listę przekierowanych kont pocztowych. W praktyce, część polecenia, oznaczona kolorem szarym jest uniwersalna, w oznaczonej na zielono skorzystałem z komendy (cmdletu) Get-Mailbox-Server. Może zostać ona zamieniona na każdy inny cmdlet wg pomysłu użytkownika.

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0→
-NonInteractive -WindowStyle Hidden -command ". 'C:\Program Files\→
Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1';→ 
Connect-ExchangeServer -auto; Get-Mailbox -Server→ 
{nazwa serwera MS Exchange} -Filter 'ForwardingAddress -ne $null' |→ 
out-file -filepath {nazwa pliku ze ścieżką}"

MG

Odnowienie certyfikatu SSL w serwerze MS Exchange 2010

Każdy kto instalował i konfigurował serwer MS Exchange wie, że jednym z jego komponentów jest dostęp do skrzynek pocztowych przez przeglądarkę (tzw. OWA – Outlook Web Access). Jak każda tego typu komunikacja OWA powinno być zabezpieczone, najczęściej za pomocą protokołu HTTPS. Żeby zrealizować takie rozwiązanie trzeba zainstalować certyfikat SSL. Standardowa procedura zakłada wygenerowanie żądania, przesłanie go do wystawcy certyfikatu, w efekcie zaś otrzymanie samego pliku z certyfikatem. Co jednak zrobić jeśli tylko odnawiamy certyfikat? Czy standardowa procedura jest konieczna?

W przypadku odnowienia certyfikatu, który podpisany został przez tego samego, zaufanego wydawcę, możemy spokojnie pominąć typową, szeroko opisywaną w Internecie, procedurę. Ponieważ podczas instalacji OWA wymagany jest serwer IIS (Internet Information Server), tak naprawdę wystarczy dokonać zmian w konfiguracji tego ostatniego.

Na początek uruchamiamy menadżera IIS (‘IIS Manager’). W lewym okienku aplikacji wybieramy definicje swojego serwera (poniżej opcji ‘Start Page’) i w środkowej sekcji wybieramy certyfikaty serwera (‘Server Certificates’). Po prawej stronie, z dostępnych opcji wybieramy Complete Certificate Request…. Po uruchomieniu okna Wizard, wskazujemy plik z certyfikatem (uwaga – domyślne rozszerzenie nie jest wymagane). Wybieramy również przyjazną nazwę, inaczej alias. Po zakończeniu czynności, program wyświetli monit Complete Certificate Request. W tym momencie potwierdzamy (OK) komunikat i przechodzimy dalej.

Tym razem rozwijamy drzewko po lewej stronie i wśród dostępnych serwerów wybieramy właściwy, podświetlając jego nazwe. Najczęściej będzie to Default Web Site. W tym momencie konieczne jest zatrzymanie usługi IIS (serwera). Po prawej stronie w sekcji Edit Site wybieramy opcje Bindings…. W okienku konfiguracyjnym, które pojawi się na środku ekranu, wybieramy https, następnie zaś, w kolejnym okienku, z rozwijanej listy wybieramy nowy certyfikat (zainstalowany w poprzednim kroku). Uruchamiamy usługę IIS. W tym momencie zakończyliśmy instalację certyfikatu SSL dla naszego OWA.

MG

Jak podejrzeć kto zajął zasób we współdzielonym kalendarzu MS Exchange

Powszechnie wiadomo, że serwer MS Exchange, oprócz standardowych skrzynek pocztowych, obsługuje skrzynki związane z zasobami. Dotyczy to zarówno lokalizacji (np. sala konferenycyjna) jak i sprzętu (np. projektor). Ta, dość wygodna funkcjonalność, umożliwia rezerwowanie zasobów w ramach organizacji. Informacje o ich zajętości można uzyskać przeglądając współdzielony kalendarz.

Niestety, standardowa konfiguracja sewera umożliwia odczytanie informacji tylko o zajętości. Nie dowiemy się natomiast kto zdążył już zarezerwować zasób. W codziennej pracy włączenie informacji o osobie rezerwującej okazuje się bardzo przydatne i pożądane.

Jak to zrobić w najprostszy sposób? Korzystając z Power Shell dostarczonego w pakiecie MS Exchange (nie mylić z Command Prompt czy Power Shell systemowym!). Po uruchomieniu Power Shell z menu systemowego, przywita nas niebieskie okienko ze znakiem zachęty. Wydajemy polecenie:

[PS] C:>Get-MailboxFolderPermission NazwaZasobu:Calendar

RunspaceId : 8706cde4-2cb5-4519-9a46-a46fcc0c450c
FolderName : Calendar
User : Default
AccessRights : {AvailabilityOnly}
Identity : Default
IsValid : True

Zwróćmy uwagę na wiersz AccessRights, w którym odczytujemy informacje o uprawnieniach: AvailabilityOnly.

Następnie wydajemy polecenie:

Set-MailboxFolderPermission NazwaZasobu:Calendar -User Default →
→ -AccessRights Reviewer

które zmieni uprawnienia dotyczące obiektu NazwaZasobu. To wszystko. Odtąd możemy zawsze sprawdzić kto zarezerwował zasób. Jeszcze tylko mały test:

[PS] C:>Get-MailboxFolderPermission NazwaZasobu:Calendar

RunspaceId : 8706cde4-2cb5-4519-9a46-a46fcc0c450c
FolderName : Calendar
User : Default
AccessRights : {Reviewer}
Identity : Default
IsValid : True

RunspaceId : 8706cde4-2cb5-4519-9a46-a46fcc0c450c
FolderName : Calendar
User : Anonymous
AccessRights : {None}
Identity : Anonymous
IsValid : True

Mam nadzieje, że wszyscy zauważyli zmianę uprawnień 🙂

MG

Problemy z logami w MS Exchange 2010

Zarządzając MS Exchange 2010 czasami możemy napotkać nieprzyjemne niespodzianki. Do jednej z nich należy blokada logów. Exchange, oprócz skrzynek pocztowych (mailbox), przechowuje logi, które zawierają m.in. całą korespondencję przechodzącą przez serwer. Z tego powodu log potrafi przybrać gigantyczne rozmiary blokując wolumin/dysk/partycję (brak wolnego miejsca na dysku). Dane te są niestety potrzebne w przypadku awaryjnego odtwarzania bazy skrzynek pocztowych, nie można ich zatem tak po prostu usunąć ręcznie. Jednak czy aby na pewno?

Zazwyczaj gdy dojdzie do blokady dysku z powodu braku miejsca sewer przestaje przetwarzać korespondencję. W takiej sytuacji trudno jest stosować skomplikowane operacje, bowiem liczy się każda chwila. Może również być tak, że nawet nie mamy gdzie przesunąć logów. Słowem impas. Musimy przede wszystkim pamiętać o dwóch podstawowych regułach:

1. Nigdy nie usuwamy logów. Możemy je co najwyżej przesunąć na inny dysk (również zewnętrzny) tak aby były dostępne na żądanie.
2. Z katalogu z logami usuwamy tylko te, które są starsze niż tzw. punkt kontroli (checkpoint).

I właśnie drugi warunek pozwali nam zadziałać ręcznie.

Procedura jest dość prosta:

• Należy odnaleźć w katalogu zawierającym logi plik z rozszerzeniem ‘*.chk’ (w większości przypadków będzie miał jedną z nazw: ‘E00.chk’, ‘E01.chk’, ‘E03.chk’ itd. )
• Korzystamy z wbudowanego narzędzia linii poleceń ‘eseutil.exe‘ i w oknie dialogowym (np. po wywołaniu command line prompt poleceniem ‘cmd.exe‘) wpisujemy np.:

"C:\Program Files\exchsrvr\bin\eseutil.exe" /MK →
→ "C:\Program Files\exchsrvr\mdbdata\E02.chk"

•  Komenda odpowie wyświetlając w okienku raport, którego najważniejsza, z naszego punktu widzenia, linijka będzie wyglądać jak:

Checkpoint (0x21EE,11B0,9A)

• Interesuja nas pierwsza wartość z nawiasu, bezpośrednio po prefiksie ‘0x’, czyli w tym przypadku ‘21EE‘
• Wyświetlamy zawartość katalogu z logami w Exploratorze systemowym i sortujemy ją wg daty
• Dobra wiadomość jest taka, że możemy ‘odchudzić’ katalog przenosząć wszystkie pliki ‘*.log’ starsze niż ‘E02021EE.log‘!

To tyle w kwestii ratowania życia administratorom 🙂 IMHO warto jest jednak unikać w przyszłości takich sytuacji i wykonywać regularnie kopie zapasowe logów (za pomocą wbudowanej w system usługi). W trakcie tego procesu logi zostaną ‘przycięte’, nie zagrozi nam zatem brak miejsca na dysku. Jednak o tym jak to zrobić napiszę innym razem…

MG

Automatyczne przesyłanie zawartości skrzynki pocztowej na inne konto z wykorzystaniem Mutt

Jakiś czas temu spotkałem się z sytuacją, w której znajomy posiadający konto poczty elektronicznej na linuksowym serwerze chciał wszystkie wiadomości przesłać jednym poleceniem na nowe konto na serwerze MS Exchange. Wiem, dla niektórych to mocno niewłaściwy kierunek ale zostałem poproszony o pomoc. Konfiguracja serwerów uniemożliwiała bezpośredni import danych. Pozostały zatem jedynie różne mniej lub bardziej udane obejścia. Długo myślałem rozważając różne możliwości i ponieważ jestem zadeklarowanym zwolennikiem terminala oraz Mutta, postanowiłem wygorzystać jego funkcje. Przyznam, że nie wiedziałem czy jest to wogóle możliwe ale Mutt po raz kolejny pozytwnie mnie zaskoczył.

Po uruchomieniu Mutta z linii poleceń:

mutt -f /path/to/mboxfile

możemy przystąpić od razu do działania. Wykorzystujemy następującą sekwencje klawiszy:

[T][.][enter]

zaznaczając wszystkie wiadomości w skrzynce. Następnie kontynuujemy:

[;][b]

i podajemy adres e-mail, na który chcemy przesłać wiadomości. Po zatwierdzeniu:

[enter]

Mutt prześle wszystkie wiadomości na nowe konto.

Nie ma rzeczy doskonałych. Dlatego i w tym przypadku trzeba wspomnieć, że wiadomości zostaną przekazane na nowe konto z tą samą datą. Jednak nasze cenne dane zostaną skopiowane i zachowane.

MG

Rola rekordu SRV w konfiguracji MS Exchange

Microsoft Exchange Server jest obecnie jednym z popularnych serwerów pracy grupowej w firmach. Nie jest to rozwiązanie tanie. Szczególnie jeśli uwzględnimy koszt budowy infrastruktury zgodnie z zaleceniami Microsfotu, koszt licencji dostępowych CAL itd. Tak czy inaczej jeżeli zdecydowaliśmy się już na zakup oprogramowania i nie mamy kilku serwerów do wykorzystania musimy liczyć się z koniecznością gruntownego zabezpieczenia naszego głównego serwera Exchange. Konfiguracja, o której mówie zakłada zainstalowanie 3 głównych ról serwera (Hub Transport Server, Mailbox Server oraz CAS – Client Access Server) na jednym serwerze. W omawianym przypadku nie zajmujemy się serwerem brzegowym (Edge Transport Server).

Ponieważ na wspomnianym serwerze instalujemy usługi dostępowe CAS (w tym dla klientów mobilnych, z poza sieci firmowej) należy zabezpieczyć go wszelkimi możliwymi środkami. Najprostszym i najtańszym rozwiązaniem jest zorganizowanie komunikacji z wykorzystaniem protokołu HTTPS (port 443). Klient poczty Microsoft Outlook posiada możliwość połączenia się z serwerem Exchange za pomocą tandemu RTP over HTTPS. Można zatem łatwo dodać regułę na firewallu firmowym, umożliwiącą komunikację z zewnątrz z serwerem Exchange na porcie 443.

Niestety Outlook wykorzystuje często funkcje autokonfiguracji działającą w oparciu o usługę Autodiscover. W tym miejscu dochodzimy do sedna problemu opisywanego w tym artykule. Jeżeli domena Active Directory (np. corp.firma.com) różni się od domeny internetowej (np. firma.com) to Outlook będzie zasypywał nas komunikatami o błędach. Istnieje wiele sposobów zapobiegania takim sytuacjom. Jednym z najbardziej skutecznych jest wykorzystanie rekordu SVR na zewnętrznych serwerach nazw. W ten sposób Outlook z każdego miejsca w internecie będzie mógł połączyć się z naszym serwerem Exchange. Rekord SRV dla Exchange będzie miał następującą postać (użyłem przykładu dla popularnego serwera bind):

_autodiscover._tcp.firma.com. IN SRV 0 5 443 server.corp.firma.com.

Musimy jeszcze pamiętać o rekordzie A dla domeny z przykładu – firma.com:

server.corp IN A 1.2.3.4

Takie rozwiązanie pozwoli uniknąć w przyszłości chóru narzekających użytkowników. I o to w zasadzie w tym wszystkim chodzi…

MG