K-NET s.c.

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

Preparing to configure Windows. Do not turn off your computer.

Moment aktualizowania systemu Windows jest dla mnie zawsze dość stresujący. Niestety, raz na jakiś czas, im częściej tym lepiej, należy aktualizować serwery. Przyznam, że po wielu latach, nadal mam mieszane uczucia i zdarza mi się odwlekać tę chwilę. Niedawno w trakcie aktualizacji jednego z serwerów produkcyjnych musiałem zmierzyć się ze 'zwisem’ w trakcie wspomnianego procesu. Kiedy od godziny obserwuje się napis ’Preparing to configure Windows. Do not turn off your computer.’ różne myśli zaczynają chodzić po głowie. Przede wszystkim nie można ulec panice i restartować ręcznie serwera bo może się to skonczyć źle… Czy jest jakaś alternatywa?

Poniżej zamieszczam procedurę dla sytuacji, w której instalacja trwa od dłuższego czasu, RDP nie działa, jednak nadal można wykonać ping do serwera.

1. Na komputerze z systemem Windows, należy założyć konto o takiej samej nazwie użytkownika i haśle, jak konto administratora w przypadku problematycznego serwera.
2. Następuje logujemy się do świeżo utworzonego konta i uruchamiamy polecenie 'services.msc’ oraz łączymy z serwerem.
3. Na liście aktywnych usług odnajdujemu ’Windows modules installer’, prawie na pewno usługa znajduje się w trybie ’Stopping’, nie można też ani jej zatrzymać ani zmienić konfiguracji. Właśnie ta usługa jest najczęściej odpowiedzialna za zwis podczas aktualizacji.
4. Programem/procesem, która uruchamia wspomnianą usługę jest ’C:\windows\servicing\trustedinstaller.exe’, musimy zatem zabić ten proces.
5. Pobieramy z Internetu narzędzie do zdalnego zarządzania procesami np. ’http://lizardsystems.com/remote-process-explorer/’.
6. Po zainstalowaniu narzędzia, podłączeniu do serwera i zabiciu procesu, serwer od razu przejdzie do ponownego uruchomienia systemu.

Mam nadzieję, że powyższy wpis okaże się pomocny i pozowoli szybko, w sposób cywilzowany, rozwiązać problem z aktualizacją.

MG

Instalacja winapcupsd na systemie serwerowym

Czy wszystkie serwery Windows powinny być zabezpieczone za pomocą zasilaczy awaryjnych? Odpowiedź jest oczywista. Jednak nie zawsze łatwa w realizacji. Co zrobić jeżeli nie mamy akurat pod ręką np. APC Smart-UPS, dedykowanego dla serwerów a pozostały nam niewykorzystane APC Back-UPS dla stacji roboczych? Zazwyczaj ten drugi pozwoli na prawidłowe zamknięcie systemu  w ciągu kilku minut, nadaje się zatem na tymczasowy zasilacz. Problem polega jednak na oprogarmowaniu dostarczanym ze sprzętem:

• APC Smart-UPS jest sprzedawany z aplikacją PowerChute Business Edition, dedykowaną dla serwerów, i nie obsługuje innych modeli zasilaczy APC,
• z kolei APC Back-UPS jest sprzedawany z aplikacją PowerChute Personal Edition, której nie możemy zainstalować na serwerowyn systemie.

Można pomysleć, że to sytuacja bez wyjścia. Tymczasem, ku mojemu zaskoczeniu, można skorzystać z oprogramowania na licencji GPL, którym jest Apcupsd. Na pewno dla każdego, kto instalował zasilacze APC pod Linuxem, ta nazwa nie brzmi obco. Na stronie projektu znajduje się odnośnik do portu dla Windows. Okazuje się, że aplikacja działa bardzo sprawnie a konfiguracja nie różni się niczym od tej z Linuxa. Jedynym, drobnym problemem, jest instalacja sterownika dostarczanego z aplikacją (należy uważnie przeczytać dokumentację i postępować zgodnie z instrukcją krok po kroku). Poza tym winapcupsd pozwala cieszyć się na serwerze pełnymi możliwościami zasilacza awaryjnego dla stacji roboczej.

MG

Polecenie 'forfiles’

Bardzo ciężko jest się przyznać do własnej niewiedzy. Jednak czasami trzeba. Ostatnio musiałem się zmierzyć z problemem usuwania logów aplikacji po 14 dniach na serwerze Windows 2008R2. Zadanie dosyś proste jeśli myślimy o środowisku Linuksa. Czy jest tak samo w przypadku Widnows? Rzecz jasna można skorzystać z bibliotek Cygwin, ale tak czy inaczej będzie to forma protezy. Dlatego zabrałem się za przeglądanie Internetu i po chwili, po raz pierwszy, natknąłem się na program/polecenie forfiles. Uruchamiane klasycznie z linii poleceń pozwala zbudować prosty skrypt, który po dodaniu do harmonogramu zadań systemowych będzie czyścił logi. Poniżej przyklad:

forfiles /S /D -14 /P "Dysk:\Log\" /M *.log /C "cmd /c del @file"

Sprawdziłem i działa całkiem dobrze:) Można powiedzieć, że w pewnym sensie Microsoft dostarczył odpowiednik linuksowego polecenia 'find’. Na zakończenie, skrócona lista opcji programu 'forfiles’:

/P nazwa_ścieżki      Wskazuje ścieżkę do rozpoczęcia wyszukiwania.                       
                      Folderem domyślnym jest bieżący katalog                       
                      roboczy (.).

/M maska_wyszukiwania Wyszukuje pliki według maski wyszukiwania.                       
                      Domyślna maska wyszukiwania to '*' .

/S                    Nakazuje poleceniu forfiles przejście do                       
                      podkatalogów. Na przykład: "DIR /S".

/C polecenie          Wskazuje polecenie, które ma być wykonane dla                       
                      każdego pliku. Ciągi polecenia powinny                       
                      być ujęte w cudzysłów.

                      Domyślne polecenie to: "cmd /c echo @file".
                      Następujące zmienne mogą być używane w                        
                      ciągu polecenia:                       
                      @file    - zwraca nazwę pliku.                        
                      @fname   - zwraca nazwę bez                                   
                                 rozszerzenia.                       
                      @ext     - zwraca tylko rozszerzenie                                   
                                 pliku.                       
                      @path    - zwraca pełną ścieżkę pliku.                       
                      @relpath - zwraca ścieżkę względną                                   
                                 pliku.                       
                      @isdir   - zwraca wartość "TRUE" dla katalogu i                                   
                                 "FALSE" dla pliku.                       
                      @fsize   - zwraca rozmiar pliku w bajtach.                       
                      @fdate   - zwraca datę ostatniej modyfikacji                                   
                                 pliku.                       
                      @ftime   - zwraca godzinę ostatniej modyfikacji                                   
                                 pliku.

/D data               Zaznacza pliki z datą ostatniej modyfikacji taką
                      samą lub późniejszą (+) bądź taką samą lub
                      wcześniejszą (-) od określonej daty, korzystając
                      z formatu "yyyy-MM-dd"; zaznacza również pliki 
                      z datą ostatniej modyfikacji taką samą lub
                      późniejszą (+) od bieżącej daty +"dd" dni bądź
                      taką samą lub wcześniejszą (-) od bieżącej daty.
                      Liczba dni "dd" musi być zzakresu 0-32768.
                      Jeżeli nie określono żadnego znaku, domyślnie
                      zostanie użyty znak "+".

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

Termometr IP dla ochrony serwerowni – część II

Jakiś czas temu opisywałem rozwiązanie polegające na zdalnym pomiarze parametrów pracy pomieszczenia (np. serwerowni). Przez ten czas zmieniła się konfiguracja obserwowanej serwerowni i pojawiły się nowe urządzenia. Pomyślałem zatem o scentralizowanym rozwiązaniu, które umożliwi obserwacje stanu większej ilości czujników a przy tym pozwoli na generację alarmów w sytuacjach krytycznych. Konfigurowanie pojedynczo każdego nowego czujnika IP jest pracochłonne i nie daje możliwości budowania złożonych akcji (alarmów), które polegają na analizie stanu kilku czujników.

Producent termometru IP udostępnił na swojej stronie darmową wersję aplikacji Wix, która umożliwia m.in.

• obserwację pomiarów z kilku urządzeń
• wykreślanie historii pomiarów
• budowanie akcji z prostą logiką warunków
• wysyłanie wiadomości alarmowych via e-mail, SMS

W tej wersji aplikacja Wix nie jest być może szczególnie zaawansowana ale oferowała funkcjonalność, której poszukiwałem. Jeśli ktoś poszukuje lekkiego i prostego w konfiguracji rozwiązania można ją śmiało polecić. Dla bardziej wymagających pozostaje zabawa z oprogramowaniem urządzeń firmy Papouch za pomocą API udostępnionego na stronie producenta.

MG

Laptop DELL, MS Windows, Office 2010 64-bit i problemy

Tym razem krótki i raczej humorystyczny wpis. Ta wiedza może uchronić Cię przed godzinami spędzonymi w poszukiwaniu rozwiązania. Rzecz dotyczy laptopów marki Dell z zainstalowanymi Windowsami w wersji 64-bitowej i pakietu MS Office 2010 64-bit. Jak się okazuje MS Word (w takiej konfiguracji) po pewnym czasie odmawia posłuszeństwa. Obajwy są dość nietypowe. Nie może otworzyć dokumentu, zawiesza się a następnie proponuje tryb awaryjny. Po naprawieniu problemu w trybie awaryjnym sytuacja powtarza się od nowa. W tym miejscu chylę czoła przed użytkownikami, którzy wpadli na to, że należy wyłączyć wtyczkę obsługującą połączenie Bluetooth – 'Opcje programu Word/Dodatki’. Krótko i na temat. Do tej pory nie mogę się otrząsnąć.

🙂

MG

Kopie zapasowe za pomocą rsync dla Windows – aktualizacja

Dokładnie 2 lata temu napisałem artykuł na temat kopii zapasowych za pomocą portu rsync dla Windows. 2 miesiące temu temat powrócił, jednak tym razem w roli głównej wystąpił Windows 2008 R2 Server. Co prawda posiada on bardzo rozbudowaną obsługę kopii zapasowych – na prawdę można przekonać się, że wiele poprawiono – aplikacja jest wygodna i niezawodna. Niemniej występują w niej niedogodności we współpracy z dyskami sieciowymi. Dla hostów windowsowych należących do Active Directory wszystko działa prawidłowo. Jednak zrzucenie kopii zapasowej na dysk udostępniony przez komputer z Linuxem (np. via SMB) stwarza problemy (szwankuje autoryzacja).

Nie pozostaje nic innego jak skorzstać ze starego, dobrego rsynca! Znalazłem w sieci bardzo dobry i stabilny port o nazwie DeltaCopy. Instalacja jest przyjemna i dość szczegółowo opisana na stronie autora. Program można uruchomić również w trybie bez instalacji. Posiada tryb usługi windows. W zasadzie jedyna rzecz, o której warto pamiętać to uprawnienia z jakimi uruchamiamy DeltaCopy w trybie usługi systemowej. Gdy zostaniemy zapytani podczas instalacji o konto i hasło dla użytkownika programu należy pozostawić puste pola. Następnie przechodzimy do widoku usług systemowych (przez Mendżer Serwera) i ustawiamy właściwości dla usługi DeltaCopy. W zakładce Logowanie należy wybrać opcję Lokalne konto systemowe.

W ten sposób otrzymujemy gotowy do użytku serwer rsync dla Windows. Należy jeszcze tylko pamiętać o otworzeniu portu 873 w Regułach przychodzących systemowego firewalla.

Ze strony komputera z Linuxem sprawa jest jeszcze prostsza (zakładam, że rsync został już zainstalowany). Przykładowe polecenie wykonujące kopie zapasową będzie miało postać:

rsync -arvz serwer.windows.2008r2::nazwa_udziału_rsync/ →
→ /sciezka_dostepu_do_katalogu_kopii_zapasowych/nazwa_kopii_zapasowej/

Dla wygody umieszczamy powyższą komendę w crontabie i możemy spać spokojnie… dopóki coś zowu się nie popsuje.

MG

Błąd MS SQL – Performance counter registry hive consistency check

Świat byłby zbyt piękny gdyby wszystko działało od razu bez problemu. Ostatnio, przy okazji instalacji SQL Server 2008 R2 Standard Edition na dziewiczym systemie operacyjnym Microsoft Windows Server 2008 R2 Standard, spotkałem się z problemem, którego rozwiązanie zajeło sporo czasu. Okazało się, że instalator zatrzymuje się na komunikacie o niespełnionej zależności – Performance counter registry hive consistency check. Nie będę się rozpisywał na temat tego błędu, który związany jest z nieprawidłowymi wpisami do rejestrów. Zresztą na internetowych forach pełno jest poradników na ten temat. Niestety większość metod nie pomaga. Na szczęście znalazłem skuteczną łatkę systemową SQL2008R2patch.exe, którą mogę szczerze polecić jako przetestowaną i działająca. Pozwala zaoszczędzić dużo czasu i bezproblemowo przygotować system do pracy 🙂

MG