08 listopada 2018

Zarządzanie chmurą z Powershell - ładowanie modułów

We wcześniejszym wpisie przedstawiłem kroki, które dobrze jest wykonać na standardowym komputerze Windows 10, przy pomocy którego chcemy administrować środowiskiem Office 365 i Azure. Piszę "i", a nie "lub", ponieważ środowiska te coraz głębiej się przenikają i o ile 2-3 lata temu można było zarządzać Office 365 bez odwoływania się do Azure, to teraz robi się to coraz trudniejsze.
Ale przejdźmy do konkretów - poszczególne obszary funkcjonalne mogą być zarządzane z poziomu Powershella, ale ponieważ są rozwijane przez różne grupy produktowe, więc jak można się domyślać, mamy do tego oddzielne moduły. Poniżej lista modułów, które dobrze jest zainstalować na swojej stacji administracyjnej.










Oprócz zaktualizowanej wersji modułu PowerShellGet widać tutaj moduły do zarządzania kontami chmurowymi i domenami chmurowymi, kontami AzureAD, również z użyciem Microsoft Graph (AzureADPreview) oraz kilka modułów dodatkowych jak np. Exch-Rest, opracowany przez Glena Scalesa, na potrzeby wykonywania akcji na Exchange Online z użyciem Rest API. Innym ciekawym modułem jest SharepointPnPPowerShellOnline, który pozwala na dodatkowe operacje na środowisku Sharepoint Online. Na powyższej liście nie widać modułów do Sharepointa online i Skype for Business Online.  Niestety trzeba je instalować i aktualizować w sposób tradycyjny. Jeżeli używamy dla kont administracyjnych MFA, to również dla Exchange online musimy pobrać dedykowany moduł. Jest on dostępny do pobrania z portalu administracyjnego Exchange Online naszego tenanta.




















W zależności od potrzeb, do wykonywania zadań administracyjnych potrzebujemy często załadować kilka modułów po kolei, do czego najwygodniej użyć skryptu. Kilka takich skryptów można znaleźć w galerii Technet lub na blogach innych specjalistów. Procedura tworzenia takiego skryptu jest opisana również w dokumentacji Office 365. Ja najczęściej korzystam z takiego skryptu. Z lenistwa w skrypcie zapisuję odpowiednie konto administracyjne i odkomentowuję odpowiednie linie dotyczące aktualnie używanych modułów:
#
# get global admin credential
#
$credential = Get-Credential admin@pepug365.onmicrosoft.com
[string]$tenant = 'pepug365'

#
# connect to Azure AD
#
Import-Module MsOnline
Connect-MsolService -credential $credential

#
# connect to Azure AIP
#

import-module AADRM
Connect-AadrmService -Credential $credential

#
# connect to Sharepoint Online
#
Import-Module Microsoft.Online.Sharepoint.PowerShell
Connect-SPOService -url https://$tenant-admin.sharepoint.com -Credential $credential


#
# connect to Exchange Online
#
#$exchSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $credential -Authentication Basic -AllowRedirection
#Import-PSSession $exchSession -DisableNameChecking -AllowClobber
#
# If MFA for Exchange admin is enabled, you should have Exchange Online Remote PowerShell Module locally
# and use cmdlet below
#
Connect-EXOPSSession -UserPrincipalName admin@pepug365.onmicrosoft.com

#
# connect to Skype for Business Online
#
Import-Module SkypeOnlineConnector
$sfboSession = New-CsOnlineSession -Credential $credential
Import-PSSession $sfboSession

#
# connecto to Microsoft Teams
#
Import-Module -Name MicrosoftTeams
Connect-MicrosoftTeams -Credential $credential

02 listopada 2018

Problemy przy migracji kontaktów Skype for Business

Jednym z bardziej uciążliwych zagadnień, na które można się natknąć w trakcie migracji użytkowników Skype for Business do usług online jest kwestia kontaktów. Starsze wersje systemów Lync i SfB 2015 w środowiskach z Exchange 2010 lub starszych przechowują kontakty użytkownika w bazie SQL, synchronizując je z lokalnym klientem. Dzięki temu użytkownik logując się do Skype for Business na innym komputerze lub urządzeniu mobilnym ma od razu dostępną listę swoich kontaktów. Serwery Exchange 2013 i nowsze korzystają z funkcjonalności Unified Contact Store (UCS), która przechowuje kontakty użytkownika SfB w jego skrzynce pocztowej, co ma swoje zalety, jednak w przypadku migracji do Office 365 bywa uciążliwe. Dlaczego? Niestety przeniesienie skrzynki użytkownika do Office 365, lub dodanie jej tam od nowa powoduje brak możliwości skopiowania kontaktów w trakcie migracji użytkownika - w rezultacie dostajemy błąd - migracja użytkownika jest nieudana. W takim przypadku powinniśmy przeprowadzić operację rollbacku - czyli wycofania się z funkcjonalności Unified Contact Store.
Jak to zrobić? Najlepiej zacząć od utworzenia polisy, która ma wyłączony UCS, przypisać taką polisę użytkownikowi, a następnie wykonać rollback.
New-CsUserServicesPolicy -Identity "NoUnifiedContactStore" -UcsAllowed $false
Grant-CsUserServicesPolicy -Identity "Konrad Sagala" -PolicyName NoUnifiedContactStore
Invoke-CsUcsRollback -Identity "Konrad Sagala"
W ten sposób, użytkownik po przełączeniu zarządzania kontaktami na sposób klasyczny nie dostanie ponownego żądania migracji kontaktów do UCS i jego kontakty będą prechowywane w SQL.
Niestety, w sytuacji gdy skrzynka jest już w Online, operacja taka nie jest możliwa w sposób standardowy. Narzędzia Microsoftowe nie potrafią zmigrować kontaktów ze skrzynki online do bazy lokalnego SfB. Musimy wykonać operację rollbacku w trybie wymuszonym:
Invoke-CsUcsRollback -Identity "Konrad Sagala" -force
Taka operacja jednak usunie nam wszystkie kontakty Skype for Business.
Jak się przed tym uchronić? Jeżeli korzystamy z UCS na lokalnym serwerze, to powinniśmy najpierw zmigrować do chmury użytkownika w SfB, a dopiero później jego skrzynkę. Jeżeli jednak skrzynka jest już w chmurze, to z pomocą przychodzi nam skrypt Michaela LaMontagne udostępniony w galerii Technet Invoke-SFBContacts, który pozwala w wygodny sposób eksportować i importować  kontakty https://gallery.technet.microsoft.com/lync/Invoke-SFBContacts-3b3ad2ef.
Warto dodać również, że opcja importu kontaktów ze Skype  for Business do Teams również nie obsługuje jeszcze UCS.