MSExchange Mailbox Replication error 1121

Wczoraj diagnozowałem uciążliwy błąd na serwerze Exchange 2013. W systemie Exchange Server 2010 i Exchange Server 2013 Mailbox Replication Service (MRS) jest odpowiedzialny za przenoszenie skrzynek, importowanie i eksportowanie danych pomiędzy bazą i plikami .pst oraz za odzyskiwanie disable’owanych i usuniętych (soft-deleted) skrzynek. Operacje przenoszenia skrzynek są definiowane przez administratora jako move requesty i wrzucane do kolejki i przetwarzane przez MRS. Po zakończeniu przenoszenia możemy ręcznie wyczyścić kolejkę zleceń, najprościej sekwencją:

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest

Jednak czasami, z różnych powodów, na serwerze pozostają śmieci, które mogą objawiać się generowaniem przez usługę MRS błędu 1121. Treść błędu może wyglądać różnie, jednak przeważnie powtarzają się w nim dwa parametry: Request GUID i Database GUID. Jeżeli wykonanie operacji:

Get-MoveRequest | Get-MoveRequestStatistics

nie pokazuje nic, czyli wg. systemu nie ma żadnych operacji przenoszenia w kolejkach, należy wtedy wykonanać następującą komendę:

Remove-MoveRequest -MoveRequestQueue 'd30f6568-2785-490e-97d5-4142a030e52c' -MailboxGuid ‘2bb0ac3e-0d79-4338-ab04-9ec728a077fe'

W powyższym poleceniu jako identyfikator kolejki wykorzystujemy pojawiający się w opisie błędu Database GUID. Błąd powinien przestać nas męczyć.

Exchange 2013 i błąd MSExchangeDiagnostics 1006

W logu aplikacyjnym serwera Exchange 2013 CU1, CU2, a nawet CU2v2 pojawia się denerwujący błąd, generowany przez usługę MSExchangeDiagnostics, jak na poniższym rysunku. Błąd jest generowany dla wszystkich wolumenów w systemie, więc pojawia się cyklicznie w grupach, zależnych od ilości dysków w danym serwerze Exchange.

 

Wynika ono ze źle ustawionego wyzwalacza, sprawdzającego ilość wolnego miejsca w systemie. Błąd powinien być naprawiony w kolejnym CU, ale póki co można się go pozbyć wyłączając wyzwalacz. W tym celu należy wyedytować plik konfiguracji usługi Microsoft.Exchange.Diagnostics.Service.exe (domyślnie w katalogu C:\Program Files\Microsoft\ExchangeServer\V15\Bin\).

Należy znaleźć licznik “ExchangeJobs.Triggers.DatabaseDriveSpaceTrigger” i zmienić jego wartość z “True” na “False”, jak widać na poniższym rysunku.

Oczywiście po zapisaniu zmian, musimy zrestartować usługę MS Exchange Diagnostics Service.

Exchange 2013 – forwardowanie maili na zewnątrz

Kilkukrotnie pytano mnie ostatnio o funkcję ustawiania forwardowania maili na zewnątrz w Exchange 2013. W poprzednich wersjach Exchange była ona dostępna, chociaż wymagała dodania obiektu typu kontakt lub mail user (reguły dostarczania wiadomości wymuszały wybór z listy dostępnych obiektów odbiorców poczty). Jednak w Exchange 2013, a konkretnie w konsoli webowej Exchange Admin Center taka funkcjonalność przestała działać.

Jednak na szczeście nie jest to problem permanentny, tylko jak się okazuje, jak zwykle Microsoft przerzucił funkcję do powłoki shellowej.

W tym celu wystarczy wykonać komendę.

Set-Mailbox -Identity "Jan Kowalski" -DeliverToMailboxAndForward $true -ForwardingSMTPAddress janek@hotmail.com

W ten sposób kopia wiadomości będzie wysyłana zarówno do skrzynki użytkownika, jak i na dodatkowe konto prywatne (oczywiście przy poufnych danych firmowych osobną kwestią jest sensowność takiego działania).

Żeby wyłączyć forwardowanie musimy wykonać tę samą komendę resetując ustawienia forwardowania:

Set-Mailbox -Identity “Jan Kowalski” -DeliverToMailboxandforward $False -ForwardingSMTPAddress $Null -ForwardingAddress $Null

Outlook 2007 a Exchange 2013

Po kilku migracjach systemu Exchange do wersji 2013 nasunęło mi się istotne pytanie - czy warto używać Outlooka 2007 z Exchange 2013? W zasadzie jest wspierany. Dokumentacja Exchange 2013 mówi, że minimalna wersja, która jest rekomendowana to Outlook 2007 Service Pack 3 z aktualizacją Outlook 2007 November 2012 (nr wersji 12.0.6665.5000). Po zainstalowaniu Outlooka 2007 SP3 i pobraniu wszystkich poprawek z Windows Update uzyskamy wersję nowszą (stan na koniec września 2013):

Czyli wszystko wygląda na pozór świetnie. Diabeł jak zwykle tkwi w szczegółach. Po pierwsze: bardzo wygodne podpowiedzi – Mail Tips i Policy Tips nie są dostępne w Outlooku 2007. Po drugie: Outlook 2007 jako pierwsza wersja wykorzystująca Web Services i usługę dostępności ma spore ograniczenia w podglądaniu (Calendar Permissions Differences in Outlook 2007, 2010 and 2013) i udostępnianiu (You can’t share your calendar in Outlook 2007) kalendarzy. No i kolejna diametralna (jak dla mnie) różnica – możliwość podłączania kilku różnych skrzynek z różnych organizacji Exchange, która pojawiła się w Outlooku 2010. W ramach tej samej oganizacji dodatkowe skrzynki podpinają nam się automatycznie.

Ciekawe porównanie funkcjonalności jest dostępne na Exchange Wiki – co prawda nie obejmuje Outlooka 2013, ale widać, że różnic jest na tyle dużo, że warto rozważyć aktualizację Office do nowszej wersji, zwłaszcza dla osób, które używają wielu kalendarzy, skrzynek współdzielonych i innych zaawansowanych funkcji.

Konferencja preMTS – 21 października w Warszawie

Ruszyła właśnie rejestracja na konferencję preMTS – spotkanie organizowane przez APN Promise przy współpracy Microsoft, Kempa, Veeama i Ciresona. Duża konferencja, jaką jest MTS to dobry pretekst, żeby spotkać się i porozmawiać na temat trochę zapomnianych w głównym nurcie MTS-u technologii.

Udało mi się namówić kilkoro świetnych specjalistów – znanych ze spotkań PEPUG i wcześniejszych konferencji MTS, jak i trochę mniej znanych (ale z dużym doświadczeniem), do podzielenia się wiedzą na temat wdrażania produktów takich jak Exchange 2013, Lync 2013, SCOM 2012, SCCM 2012 i SCSM 2012. Powiemy również o produktach powiązanych z aplikacjami Microsoftu – urządzeniach (telefony, Load Balancery) i oprogramowaniu innych dostawców rozszerzających funkcjonalność tych produktów. Serdecznie zapraszam na konferencję.

Migracja do Exchange 2013 w trybie hybrydowym

Jeżeli organizacja Exchange w firmie jest w konfiguracji hybrydowej (współdzielenie przestrzeni adresowej z usługą Office365), to przy próbie rozszerzenia schematu do wersji Exchange 2013 otrzymamy błąd:

A hybrid deployment with Office 365 has been detected. Please ensure that you are running setup with the /TenantOrganizationConfig switch. To use the TenantOrganizationConfig switch you must first connect to your Exchange Online tenant via PowerShell and execute the following command: "Get-OrganizationConfig | Export-Clixml -Path MyTenantOrganizationConfig.XML". Once the XML file has been generated, run setup with the TenantOrganizationConfig switch as follows "/TenantOrganizationConfig MyTenantOrganizationConfig.XML". If you continue to see this this message then it indicates that either the XML file specified is corrupt, or you are attempting to upgrade your on-premises Exchange installation to a build that isn't compatible with the Exchange version of your Office 365 tenant. Your Office 365 tenant must be upgraded to a compatible version of Exchange before upgrading you r on-premises Exchange installation. For more information, see: http://go.microsoft.com/fwlink/?LinkId=262888

For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.DidTenantSettingCreatedAnException.aspx

Jak widać, rozwiązanie problemu jest proste i wystarczy przeczytać powyższy tekst. Oczywiście należy również sprawdzić, czy nasz tenant został zaktualizowany do wersji 2013 (nadal jest jeszcze sporo organizacji z Exchange 2010), czyli atrybut AdminDisplayVersion musi być nie niższy niż 15.0.620.28 – aktualna wersja to 15.0.702.21 (dla tenantów z Exchange 2010 ostatnio miał on wartość 14.16.175.8).

Czyli na nowym serwerze, który przygotowaliśmy pod Exchange 2013 uruchamiamy z PoweShella sekwencję poleceń:

setup.exe /preparead /IAcceptExchangeServerLicenseTerms

$LiveCred = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

Import-PSSession $Session

Get-OrganizationConfig | Export-Clixml -path c:\install\MyTenant.xml

setup.exe /preparead /IAcceptExchangeServerLicenseTerms /TenantOrganizationConfig:c:\install\MyTenant.xml

Tym razem rozszerzenie schematu powinno powieść się bez problemów i będziemy mogli kontynuować instalację. W przykładzie podałem opcję /preparead, ponieważ /prepareschema w wersji CU1 nie działało poprawnie.

Problem z aktualizacją Antimalware w Exchange 2013

Jedną z zalet Exchange 2013 jest wbudowany silnik antimalware (de facto okrojona wersja Forefront Protection for Exchange 2010). W trakcie instalacji Exchange 2013 instalator domyślnie podpowiada opcję włączenia silnika, co jeżeli klient nie używa innego produktu antywirusowego przeważnie akceptuję. Oczywiście można nie włączać w trakcie instalacji, ale zrobić to później, wykonując skrypt Enable-antimalwareScanning.ps1, który znajduje się w folderze Scripts katalogu instalacyjnego Exchange 2013.

Dzisiaj kolega prosił mnie o pomoc w rozwiązaniu problemu z brakiem aktualizacji silnika, na który natrafił. Sprawdziłem kilka wdrożonych przeze mnie serwerów i faktycznie na niektórych znalazłem pojawiający się okresowo (co 30 minut, tak jak domyślnie skonfigurowana jest aktualizacja silnika) błąd 6027, jak na poniższym rysunku:

Jak okazało się, problem ten pojawia się na wielu serwerach i pytania o ten problem wiszą na wielu forach tematycznych. W niektórych miejscach znalazłem informację, że problem został rozwiązany po aktualizacji do Exchange 2013 CU1, choć tylko w części przypadków, ale problem pojawił się również na serwerach, które były instalowane od początku na wersji Exchange 2013 CU2. Można spróbować ręcznie zaktualizować silnik, zgodnie z procedurą opisaną w dokumentacji Exchange, ale niestety nie rozwiązało to problemu. Żeby sprawdzić, czy nasz serwer pobiera (lub pobierał) poprawki antymalware, poza szukaniem w logu aplikacyjnym powyższego błędu, warto sprawdzić status aktualizacji poprawek, przy pomocy komendy Get-EngineUpdateInformation. Żeby jednak było trudniej, ten cmdlet nie jest dostępny domyślnie w Exchange Management Shell (!). Musimy ręcznie załadować bibliotekę cmdletów Forefrontowych:

Add-PSSnapin -Name Microsoft.Forefront.Filtering.Management.PowerShell

Teraz już komenda zadziała, jednak na diagnozowanym serwerze, jak widać nigdy nie udało się pobrać aktualizacji:

Po różnych próbach i testach, zaaplikowałem procedurę opisaną w artykule dotyczącym problemów z aktualizacją manifestów dla nieaktualnych silników antywirusowych - http://support.microsoft.com/kb/929074/pl.

Po ręcznym pobraniu pliku manifestu ze strony Microsoft http://forefrontdl.microsoft.com/server/scanengineupdate/x86/Microsoft/Package/manifest.cab sprawdziłem w przeglądarce aktualną wersję silnika (w tym przypadku był to numer 1308200001), a następnie również ręcznie pobrałem pełen pakiet aktualizacji wpisując url (oczywiście już jutro będzie to inny numerek) http://forefrontdl.microsoft.com/server/scanengineupdate/x86/Microsoft/Package/1308200001/Microsoft_fullpkg.cab

zgodnie z podanym w artykule 929074 wzorcem dla silnika Microsoft http://forefrontdl.microsoft.com/server/scanengineupdate/x86/scanengine_name/Package/version_number/scanengine_name_fullpkg.cab.

Po rozpakowaniu pliku do tymczasowego katalogu zaktualizowałem zawartość folderu Bin silnika (domyślnie jest to katalog C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\amd64\Microsoft\bin) i zrestartowałem usługę Microsoft Filtering Management Service. Po ponownym uruchomieniu usługi i chwili odczekania w logach pojawiła się informacja o poprawnym pobraniu aktualizacji. Ponowne wykonanie cmdleta get-engineupdateinformation pokazało informację o aktualnej wersji silnika i poprawnym wykonaniu aktualizacji:

Problemy z poprawkami Microsoft – MS13-061

Dopiero co zespół Exchange musiał modyfikowaćpoprawkę CU2 dla Exchange 2013, a w zeszłym tygodniu pojawił się kolejny babol. Krytyczna poprawka bezpieczeństwa MS13-061 dla Exchange 2013 CU1 i CU2 skutecznie rozwala indeksowanie na serwerze skrzynkowym Exchange 2013. Nie jest to błąd, który widać od razu z poziomu klienta (choć w logu aplikacyjnym serwera robi się czerwono), więc nie wszyscy administratorzy, którzy pobrali  i zainstalowali tę poprawkę na serwerach Exchange zauważyli problem, jednakże sprawdza się teza, że dobrze jest sprawdzić kanały RSS, blogi i grupy dyskusyjne przez aplikacją nowych poprawek.

Co prawda zespół Exchange szybko problem zauważył, a nawet wydany został artykuł KB 2879739, co zostało opisane na blogu produktowym - Exchange 2013 Security Update MS13-061 Status Update, ale jednak mleko się wylało. Procedura naprawcza nie jest skomplikowana, a nawet dla leniwych Michel de Rooij opublikował na TechNet Gallery skrypt, który wyręcza nas w ręcznym grzebaniu w rejestrach, warto jednak mieć świadomość, że taki problem istnieje.

Na szczęście paczki poprawek dla starszych wersji Exchange, które zawierają poprawkę MS13-061, nie powodują takich problemów:

Update Rollup 11 for Exchange Server 2007 SP3

Update Rollup 7 for Exchange Server 2010 SP2

Update Rollup 2 for Exchange Server 2010 SP3

Problemy z poprawkami Microsoft - WAS

Ostatnio Microsoft nieźle namieszał w kwestii poprawek. Ku pamięci i przestrodze dla innych zapiszę kilka uwag w tym temacie.

Jednym z niemiłych faktów, jaki mnie ostatnio zaskoczył był problem z Office Web Apps Serverem 2013 (WAS). Skonfigurowaliśmy serwer, po jakimś czasie zostały zainstalowane poprawki z Windows Update, między innymi do WAS-a, no i zaczęło sypać błędami (przeważnie 1000 i 1026 – obrazki poniżej).

Utylizacja procesorów serwera WAS skoczyła na 100%, z czego większość zasobożernych procesów była związana z obsługą błędów.

Okazało się, że automatyczna instalacja poprawek skutecznie rozwaliła konfigurację Office Web Apps Servera 2013. Na szczęście jest ona stosunkowo prosta. Niestety, poprawka KB2760445 nie ma opcji odinstalowania, co powoduje konieczność odinstalowania WAS, zainstalowania go ponownie, wgrania poprawek i dopiero w tym momencie ponownego skonfigurowania farmy WAS (lub dodania danego serwera do farmy składającej się z kilku serwerów (Remove-OfficeWebAppsMachine). Procedura instalacji poprawek do WAS opisana jest na stronach dokumentacji produktu.

Tylko dlaczego te poprawki są dostępne przez Windows Update?

Integracja Exchange 2013 i Lync Server 2013 - OWA

W poprzednim poście pisałem o podstawach integracji pomiędzy Lync 2013 i Exchange 2013, teraz pójdę kawałek dalej – do integracji z poziomu OWA. W Exchange 2010 trzeba było dodatkowo instalować moduły odpowiadające za integrację, poprawki, a teraz wystarczy kilka komend i po sprawie. Pierwszym krokiem jest włączenie funkcjonalności na poziomie witryny OWA.

Robimy to dwuetapowo (przy założeniu, że role Mailbox i CAS mamy na tym samym serwerze) – najpierw wskazujemy, że integracja jest włączona i jaki jest jej typ:

Get-OwaVirtualDirectory "SRV-EX1\owa (Default Web Site)" | Set-OwaVirtualDirectory -InstantMessagingType OCS -InstantMessagingEnabled $true

Następnie musimy wyedytować plik web.config, znajdujący się w katalogu C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa (przy wybranej domyślnej ścieżce instalacji). W sekcji <appSettings> musimy dodać dwa klucze – wskazujący na certyfikat, wykorzystywany dla witryny OWA – musimy podać jego Thumbprint, oraz FQDN serwera FrontEnd (lub puli) Lynca.

Thumprint kopiujemy sobie z właściwości certyfikatu podpiętego do usług IIS w konsoli EAC:

Kolejnym krokiem jest dodanie zaufanej aplikacji po stronie serwera Lync – w tym celu musimy w Topology Builderze dodać serwer Exchange do puli zaufanych serwerów:

Po zaznaczeniu w ostatnim kroku kreatora puli Lyncowej, wystarczy opublikować zmiany w bazie konfiguracyjnej. Jeżeli włączamy tylko integrację dla OWA, to możemy dodatkowo wyłączyć replikację danych konfiguracyjnych do zdefiniowanej właśnie puli

W tym momencie po zalogowaniu się do OWA powinniśmy zobaczyć status naszego użytkownika:

Jednakże, dla świętego spokoju i prawidłowej konfiguracji powinniśmy dodać również zaufaną aplikację na serwerze Lyncowym:

new-CsTrustedApplication -ApplicationId "SRV-EX1" -TrustedApplicationPoolFqdn srv-ex1.pepug.org -port 5070

Port oczywiście możemy wybrać dowolny, nieprzypisany na serwerze  Exchange do innych usług. Ciekawą instrukcję, trochę bardziej rozbudowanej konfiguracji z oddzielnymi serwerami CAS i Mailbox pokazał na swoim blogu Oliver Moazzezi.

Integracja Exchange 2013 i Lync Server 2013

Na pierwszy rzut oka integracja Exchange 2013 i Lync Servera 2013 wygląda prosto, ale trzeba uwzględnić kilka istotnych elementów. Pierwszym z nich są certyfikaty, wykorzystywane do wzajemnego uwierzytelnienia serwerów. Dla serwera Lync Server 2013 można użyć wygenerowanego na potrzeby usług Front End certyfikatu, można również wygenerować oddzielny certyfikat, korzystając z Lync Server Deploymnet Wizarda – gdzie w kroku 3 konfiguracji serwera możemy uruchomić kreator, który pomoże nam wygenerować odpowiedni certyfikat typu OAuthTokenIssuer certificate. Jednakże do usług wzajemnego uwierzytelniania serwerów można przypisać dowolny inny certyfikat webowy, pod warunkiem, że:

• Certyfikat zawiera nazwę domeny SIP w polu Subject.
• Ten sam certyfikat jest przypisany jako OAuthTokenIssuer na każdym serwerze Front End.
• Certyfikat ma długość co najmniej 2048 bitów.

Kolejnym krokiem jest wskazanie Lyncowi, pod jakim URL dostępna jest exchange’owa usługa autodiscover – klient lincowy wykorzystywać ją będzie do sprawdzania dostępności kalendarzy innych użytkowników. W tym celu musimy na serwerze Lync 2013 wykonać komendę:

Set-CsOAuthConfiguration -Identity global -ExchangeAutodiscoverUrl "https://autodiscover.pepug.org/autodiscover/autodiscover.svc”

lub po prostu

Set-CsOAuthConfiguration -ExchangeAutodiscoverUrl "https://autodiscover.pepug.org/autodiscover/autodiscover.svc”

Oczywiście musimy się najpierw upewnić, jaką postać ma wewnętrzny URL usługi autodiscover. Możemy to łatwo sprawdzić z poziomu serwera Exchange komendą:

Get-ClientAccessServer | select name,AutoDiscoverServiceInternalUri

Kolejnym krokiem jest wskazanie serwerowi Exchange serwera Lynca jako aplikacji partnerskiej i vice-versa. W tym celu musimy wykonać na serwerze Exchange skrypt Configure-EnterprisePartnerApplication.ps1, który znajduje się w domyślnym katalogu Scripts binarek Exchange (domyślnie c:\Program Files\Microsoft\Exchange Server\V15\Scripts)

Configure-EnterprisePartnerApplication.ps1 -AuthMetaDataUrl 'https://lyncfe.pepug.org/metadata/json/1' -ApplicationType Lync

Po tej operacji musimy zrestartować IIS na serwerze Exchange komendą iisreset.

Analogicznie postepujemy po stronie serwera Lync 2013, tym razem wykorzystując standardowy cmdlet:

New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl https://autodiscover.pepug.org/autodiscover/metadata/json/1

Jeżeli wszystko wykonaliśmy poprawnie, to wykonanie testu

Test-CsExStorageConnectivity -SipUri "sip:konrad.sagala@pepug.org"

zwróci nam wynik poprawny.

Więcej w dokumentacji - http://technet.microsoft.com/en-us/library/jj688098.aspx

W ten sposób mamy włączony Unified Contact Store. Teraz tylko trzeba zmigrować kontakty użytkowników z bazy Lyncowej do Exchange.

Automatyczne przekierowanie strony startowej OWA w Exchange 2013

Jakiś czas temu pisałem o ciekawym skrypcie do automatyzacji przekierowywania strony głównej hosta na stronę logowania OWA. W Exchange 2013 Microsoft dodał do konfiguracji serwerów dodatkową bibliotekę, która automatycznie realizuje takie przekierowanie – OWAUrlModule. Po zainstalowaniu serwera Exchange, jeżeli wpiszemy jego nazwę – np. https://owa.contoso.com, to moduł automatycznie przekieruje nas na stronę https://owa.contoso.com/owa, czyli uprości użytkownikom życie. W kolejnych Cumulative Update’ach moduł jest coraz bardziej rozbudowywany – w CU2 potrafi przekierowywać użytkownika również do skrzynki na starym serwerze Exchange 2010, jednak nie każda konfiguracja działa optymalnie. W przypadkach, gdy np. mamy kilka serwerów w load balancingu, wykorzystujemy jakieś niestandardowe mechanizmy czy adresy URL, lepiej jest jednak jak na razie wyłączyć moduł i zrobić przekierowanie po staremu. W tym celu trzeba wyedytować plik %systemdrive%\inetpub\wwwroot\web.config i zakomentować definicję modułu:

<system.webServer>
<modules>
<add name="OwaUrlModule" type="Microsoft.Exchange.HttpProxy.OwaUrlModule,Microsoft.Exchange.OwaUrlModule,Version=15.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35" preCondition="" />
</modules>
</system.webServer>

W tym celu trzeba wstawić komentarz:

<system.webServer>
<!-- <modules>
<add name="OwaUrlModule" type="Microsoft.Exchange.HttpProxy.OwaUrlModule,Microsoft.Exchange.OwaUrlModule,Version=15.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35" preCondition="" />
</modules> -->
</system.webServer>

Następnie należy w tym samym katalogu utworzyć plik default.htm o treści:

<html><meta http-equiv="REFRESH" content="0;url=/owa"></HEAD></html>

Dobrze jest również dodać definicję błędu, przekierowującą stronę:

Sprawdzałem w konfiguracji HLB z kilkoma serwerami Exchange 2013 CU2 – działa. Poradę znalazłem na blogu Jeffa Guilleta.

Problem z automapowaniem dodatkowych skrzynek w Outlooku

Kojarzycie, jak działa automapowanie dodatkowych skrzynek w Outlooku? Począwszy od wersji Exchange 2010 SP1, jeżeli dodajemy uprawnienia do skrzynki innym użytkownikom, automatycznie jest włączane mapowanie skrzynki, tak że w Outlooku pojawia się nam dodatkowa skrzynka. Najprościej dodać uprawnienia z konsoli graficznej (EMC w Exchange 2010 lub EAC w Exchange 2013), jednak wykorzystując PowerShell jest prawie tak samo łatwo. Jeżeli chcemy dodać koledze Jankowi pełne prawa do skrzynki np. sekretariatu, to jest to bardzo proste:

Add-MailboxPermission –Identity Sekretariat –User pepug\jankowalski –AccessRights FullAccess

Opcja automapowania ustawiana jest automatycznie i w Outlooku 2007 lub nowszym powinno zadziałać po krótkiej chwili. Jeżeli jednak tego nie chcemy (ktoś ma dostęp do kilkunastu czy nawet kilkudziesięciu skrzynek i otwieranie outlooka i jego synchronizacja mogłaby trwać zbyt długo), to możemy opcję wyłączyć (ta możliwość pojawiła się w Exchange 2010 Service Pack 2):

Add-MailboxPermission –Identity Sekretariat –User pepug\jankowalski –AccessRights FullAccess –Automapping $false

Jeżeli zabieramy użytkownikowi Exchange uprawnienia do dodatkowej skrzynki, mapowanie jest automatycznie zdejmowane, jednak opcja ta niestety nie zawsze działa. I tak można dorobić się kilku folderów “widm”, które tylko niepotrzebnie generują nam błędy synchronizacji (nie można ich zamknąć z poziomu Outlooka). Żeby pozbyć się takich problemów, musimy wejść w atrybuty konta (sekretariatu, nawiązując do powyższego przykładu) i usunąć nazwę problematycznej skrzynki z listy delegatów konta (jak na poniższym rusynku):

Więcej na temat automappingu w Exchange 2010 można przeczytać w artykule Neila Hobsona.

Aktualizacja Exchange 2013 CU2

Microsoft wydał poprawioną wersję CU2 dla Exchange 2013 – oryginalna wersja pakietu czyściła uprawnienia folderów publicznych przy przeniesieniu skrzynki folderów publicznych między bazami.

Przy okazji Microsoft zmienił nazewnictwo pakietu – zamiast nic nie mówiącego Exchange-x64.exe, można odczytać teraz nr artykułu z opisem poprawki.

Exchange 2013 CU2 już dostępny

Dzisiaj pojawił się długo czekiwany i zapowiedziany na amerykańskim TechEdzie pakiet poprawek CU2 do Exchange 2013. Zmian jest dużo, niektórzy mogliby je nawet porównywaćz Service Packiem, ale jak na razie to tylko planowa paczka aktualizacji, udostępniona zgodnie z nowym modelem serwisowania.

Jednak oprócz usunięcia części problemów i błędów CU2 wprowadza szereg ulepszeń. Część z nich byłą dostępna już w Exchange 2010 SP2, jednak nie znalazły się w wersji 2013 RTM.

Dużo kontrowersji wywołało ograniczenie ilości baz danych w Exchange 2013 Enterprise RTM do 50, co zostało zmienione w CU2 – przywrócono maksymalną ilość 100 baz danych.

Kolejne usprawnienia wprowadzono w obszarach:

OWA Redirection - przekierowanie między site’ami, z SSO

High Availability – dodano nowy serwis DAG Management Service

Managed Availability – rozszerzono funkcjonalność responderów, mogą teraz obsługiwać całą grupę serwerową (DAG)

Cmdlet Help – na bierząco można zaktualizować pomoc dla cmdletów, nie czekając na kolejny pakiet poprawek

OWA Search Improvements – poprawiono prezentację wyników w ramach wątków konwersacyjnych

Malware Filter Rules – dodano cmdlety, pozwalające tworzyć polisy filtrujące dla grup i domen pocztowych.

Dokładniejsza lista poprawek znajduje się na blogu grupy produktowej.

Exchange 2013 RTM CU2 rozszerza schemat Active Directory. Przed instalacją pakietu należy uruchomić z odpowiednimi uprawnieniami polecenie setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms.

Exchange 2013 RTM CU2 zawiera również modyfikacje Active Directory (np. aktualizacje RBAC, uwzględniające nowe cmdlety). Czyli wykonanie polecenia setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms też może być pomocne.

Lipcowa poprawka dla Lync Server 2013

Pojawiła się kolejna poprawka do serwera Lync 2013. Zawiera całkiem sporo poprawionych komponentów, Oprócz ściągnięcia poprawki, po jej zainstalowaniu należy zaktualizować schemat baz danych, zgodnie z opisem w artykule KB2809243. Ponieważ poprawka również aktualizuje Unified Communications Web API, na koniec należy uruchomić Bootstrapera, który zweryfikuje konfigurację komponentów:

%ProgramFiles%\Microsoft Lync Server 2013\Deployment\Bootstrapper.exe

TechEd Europe 2013

W piątek wróciłem z tegorocznej edycji europejskiego TechEdu (TEE 2013) do domu, moja walizka dojechała dzisiaj,- ale jednak dojechała, więc nie ma co narzekać. W zeszłym roku nie uczestniczyłem w TEE, więc po nie najlepszych wspomnieniach z TEE 2010 w Berlinie byłem bardzo ciekawy tegorocznej edycji. Po dotarciu do centrum konferencyjnego, które jest ogromne, pewne zdziwienie wywołały skromne bilbordy, które nawet z bliska łatwo było przeoczyć. Jednak wnętrze centrum zrobiło na mnie wrażenie.

Konferencja przeleciała jak z bicza strzelił, widziałem dużo ciekawych sesji, włączając w to najnowsze wersje Windows Server 2012 R2 i System Center 2012 R2 (nawet z aktualnymi labami), uczestnicy dostali również pendrive z obrazem instalacyjnym Windows 8.1 (zainstalowany zaraz po powrocie do Polski). Organizatorzy zapewnili trzy ciekawe imprezy wieczorne – chociaż niektórzy narzekali, że Polska to reszta świata i nie miałą dedykowanego spotkania, to jednak było bardzo sympatycznie. Dobrą rzeczą jest dostępność sesji i slajdów na portalu Channel 9.

Trochę zdziwiła mnie ilość wystawców w pawilonie TechExpo – w tym roku było ich mniej niż poprzednio, chociaż cześć z nich była bardzo ciekawa, w tym stoisko polskiej firmy CodeTwo. Ciekawie prezentowały się też stoiska Microsoftu – zwłaszcza Lynca 2013 z szeroką gamą urządzeń, podobnie Windows Phone i rozwiązań chmury (Azure i Office365).

Podobno również uczestników w tym roku było mniej, choć w czasie lunchu nie było tego widać.

Zaskoczył mnie również brak osób z polskiego biura Microsoft, ale rozumiem, że koniec roku fiskalnego i duże zmiany personalne miały na to swój znaczący wpływ. Miejmy nadzieję, że nie wpłynie to negatywnie na tegoroczny MTS w Warszawie.

Bogatszy o nowe doświadczenia wróciłem do biura by z naładowanymi akumulatorami, ruszyć do testowania najświeższych produktów.

Lync 2013 na tabletach z androidem

Po testach Lynca na Surface i iPadzie, przyszedł czas na tablety androidowe. No i tu mamy podstawowy problem. Oficjalnie urządzenia takie nie są wspierane (mam nadzieję, że ten stan się wkrótce zmieni). Co nie znaczy, że Lync 2013 nie będzie działać na tablecie z androidem. Podstawowym kryterium, podobnie jak jest wersja systemu (co najmniej 4.0), no i oczywiście “wyświetlalność” aplikacji w Google Play. Część urządzeń (np. Asus Transformer) nie pokaże nam aplikacji i bez dodatkowych sztuczek nie ma szans. Niektóre tablety (bardziej rozpoznawane jako generic device) pokażą nam w sklepiku Lynca i można go zainstalować. Na pewno warto zerknąć do dwóch artykułów, żeby dowiedzieć się więcej:

• KB Article 2834018: Troubleshooting issues with Microsoft Lync 2013 for Android
• KB Article 2829747: Android smartphone devices that are supported for use with Lync 2013 for Android

Integracja Lync ze Skype – ustawienia po stronie klienta

W poprzednim poście wspomniałem, co należy zrobić, żeby na poziomie serwera Lync Servera 2013 skonfigurować federację ze Skype.

Mając skonfigurowaną organizację Lync 2013 do federacji ze Skype (rysunek 1)

i przypisaną użytkownikowi polisę zezwalającą na połączenia ze sfederowanymi użytkownikami (rysunek 2):

Możemy już łączyć się ze znajomymi ze Skype. Ale ponieważ nie chcemy, żeby kilka milionów użytkowników Skype zamęczyło nas swoimi problemami, więc w ustawieniach federacji powinniśmy ustawić opcję, że połączenia mogą być tylko z osobami, które mamy w swoich kontaktach (rysunek 1). Tak jest bezpieczniej. Musimy więc zatem dodać najpierw użytkownika Skype do swoich kontaktów. Jak to zrobić?

                  

W Lyncu klikamy na znaczek ludzika z plusem i z opcji “Add a Contact Not in My Organization” wybieramy opcję Skype.i podajemy adres naszego znajomego ze Skype’a, dodajemy do konkretnej grupy i ustawiamy opcje prywatności – co ważne konto Skype musi być powiązane z Microsoft Id (czyli kontakt musi używać jednej z nowszych wersji klienta Skype i przy poerwszym logowaniu po aktualizacji oprogramowania wybrać opcję powiązania konta z Microsoft Id). Tu pojawia się jeszcze jedno ale – konta Microsoft Id mogą używać identyfikatora w jednej z domen Microsoftowych - @live.com, @hotmail.com lub @outlook.com. Można jednak utworzyć sobie konto Microsoft Id z wykorzystaniem adresu w dowolnej innej domenie pocztowej. Czy jeżeli mamy Microsoft Id z kontem w domenie gmail.com, to czy w takim przypadku federacja zadziała? W trakcie tworzenia kontaktu należy w takim przypadku podać identyfikator w specyficznym formacie:

user(domain name)@msn.com

Czyli np konrad(gmail.com)@msn.com

Dodatkowo, można po stronie klienta ustawić opcje zezwalania na otrzymywanie zaproszeń w Lyncu, przy jednoczesnym zablokowaniu innej komunikacji (gdyby administrator zmienił ustawienie globalne):

Jak działa integracja w praktyce pokażemy na spotkaniach w ramach Office 2013 Community Launch.

Integracja Lync ze Skype – po stronie serwera Lync

Jedną ze sztandarowych funkcji Lync Servera 2013, zarówno w wersji On-Premise jak i Online była integracja z klientami Skype. Niestety jak ostatnio często bywa z wersjami RTM, funkcjonalność ta nie była gotowa w momencie wydania nowej wersji serwera. Na szczęście już od kilku tygodni integracja zaczęła działać, zarówno w zakresie Instant Messaging jak i rozmów audio. Konfiguracja takiej integracji nie jest jednak taka oczywista. W przypadku Lync Online wystarczy zaznaczyć jedną opcję w parametrach organizacji dla usługi Lync (opcja ta zresztą jest domyślnie włączona), jak widać na poniższym rysunku:

W przypadku Lync Server 2013 jest to trochę bardziej czasochłonne i niektóre kroki nie są takie oczywiste. Właśnie pojawił się dokument Provisioning Guide for Lync-Skype Connectivity, opisujący szczegółowo taką konfigurację, zachęcam do lektury. NA co warto zwrócić uwagę?Jeżeli mamy zainstalowany i skonfigurowany do federacji z publicznymi komunikatorami (PIC) serwer Lync 2013 z rolą Edge (tak, nie wymaga dodatkowej licencji) i polisy dla użytkowników, zezwalające na federację, to podstawę już mamy.  Pierwszą, najbardziej czasochłonną kwestią jest uruchomienie federacji z publiczną domeną Microsoft, a właściwie Skype. W tym celu musimy zalogować się na witrynie https://pic.lync.com swoim identyfikatorem Microsoft Id, najlepiej powiązanym z domeną firmową.

Następnie wymieramy rodzaj umowy, jaką mamy podpisaną z firmą Microsoft w zakresie korzystania z Lynca:

Przeważnie będzie to pierwsza opcja – umowa wolumenowa, chociaż np. partnerzy Microsoft o statusie Gold mogą wybrać opcję drugą. Po podaniu nr umowy, przechodzimy do kolejnego kroku, w którym możemy uruchomić usługę, przedłużyć ją, zaktualizować dane lub wyłączyć usługę.

Kolejnym krokiem jest podanie domeny SIP, którą chcemy wskazać jako sfederowaną z domeną skype.com i serwer(y) Edge z usługą dostępową Access Edge – maksymalnie 10 serwerów. No i po zatwierdzeniu zgłoszenia czekamy na realizację – maksymalnie 30 dni,ale jak mamy szczęście, to dużo szybciej.

Może się tu pojawić problem w przypadku modelu hybrydowego – nasza domena SIP jest już aktywowana do federacji po stronie Lync Online – musimy wtedy dokonać wyboru i wyłączyć usługę po stronie Office365.

Ostatnim krokiem po stronie serwera (przy wcześniejszym założeniu że mamy już ) jest zmiana konfiguracji Public Providera dla Messangera. W tym celu z poziomu Lync Server Management Shella musimy wykonać dwie komendy:

Remove-CsPublicProvider -Identity Messenger

New-CsPublicProvider -Identity Skype -ProxyFqdn federation.messenger.msn.com -IconUrl "https://images.edge.messenger.live.com/Messenger_16x16.png" -VerificationLevel 2 -Enabled 1

W zależności od sposobu wdrożenia Lynca (upgrade z Lynca 2010) Provider do usunięcia może nazywać się MSN.