Każdy administrator Exchange, zarówno on-premises, jak i online, od czasu do czasu spotyka się z zadaniem migracyjnym - przeniesienie skrzynki do innej bazy czy też z lokalnego serwera do chmury jest stosunkowo prostym zadaniem, jednak żeby nie zakończyło się niepowodzeniem, należało w zadaniu migracyjnym ustawić wartość 'Bad Item Limit' na odpowiednio wysoką wartość (ja przeważnie używam 50). Działanie to miało umożliwić poprawne wykonanie migracji pomimo natrafienia na pewną ilość (nie większą niż wskazany limit) uszkodzonych elementów w skrzynce użytkownika. Po zakończeniu migracji mogliśmy zweryfikować log dla takiej skrzynki i sprawdzić, jakiego rodzaju elementy nie zostały zmigrowane. Jednak przy każdym zadaniu migracyjnym należało o tym pamiętać (pojawienie się nawet jednego elementu powodowało "wywalenie się" migracji), co bywało nieco uciążliwe, zwłaszcza dla osób z mniejszym doświadczeniem. Pod koniec zeszłego roku Microsoft wprowadził alternatywny mechanizm w Exchange Online o nazwie Data Consistency Score (DCS). Na podstawie znalezionych w trakcie migracji uszkodzonych elementów, raport pomigracyjny określa wynik migracji jako Perfect, Good, Investigate lub Poor. Migracja oznaczona jako Investigate wymaga dodatkowej akceptacji przez administratora (przez portal lub Powershell), oczywiście po weryfikacji, jakie problemy pojawiły się w trakcie. Migracja oznaczona jako Poor, nie może być zakończona bez eskalacji do supportu usługi. DCS zastępuje również użycie opcji -LargeItemLimit, co czasami bywa niezbędne przy użytkownikach z niestandardowymi wymaganiami.
Oczywiście, jeżeli użyjemy parametr -BadItemLimit definiując moverequest dla chmury, to nasz wybór będzie miał preferencję nad DCS, ale domyślny tryb migracyjny korzysta z nowego mechanizmu scoringu. Docelowo zarówno -BadItemLimit jak i -LargeItemLimit zostaną całkowicie zastąpione mechanizmem DCS. Więc informacji o Data Consistency Score można znaleźć w dokumentacji producenta.
Brak komentarzy:
Prześlij komentarz