Azure Stack GA

cloud computing australia

kilka luźnych myśli…

po pierwsze Azure Stack jest w GA i od przyszłego miesiąca można już zamawiać . oczywiście na liście 46 krajów Polski nie ma. dla tych, którzy jeszcze o Azure Stack nic nie wiedzą – jest to rozwiązanie Appliance, które można wstawić do własnej serwerowni, i korzystać z niego jak z Azure.. .którym w zasadzie jest. odwrócenie starej idei, gdzie firmy dzierżawiły kawałek publicznego Data Center aby mieć je do własnego użytkq. tutaj odwrotnie – wstawia się zabawki dostawcy do własnej serwerowni. ale rozlicza się nadal tak, jak Azure – czyli nie jest to zastępstwo dla Azure Packa, czy dobrze wdrożonego System Center. pomysł zaiste ciekawy, niewątpliwie organizacje, które z powodów wydajnościowych czy bezpieczeństwa chcą mieć dane u siebie, mogą teraz udomowić kawałek Azure (:

pełnej funkcjonalności nie ma, a część funkcji zawsze będzie potrzebowała sięgnąć gdzieś na zewnątrz, ale wiele dodatkowych scenariuszy to otwiera.

najciekawszy art jaki znalazłem dot. dostępności Azure Stack jest analizą rynkową. zabawne jest, że po kilq latach całego zamieszania wokół chmury, nadal powinno się zaczynać od 'swojej definicji’ chmury. w podlinkowanym arcie pada cytat, że według AWS 'chmura’ oznacza zawsze i tylko 'chmurę publiczną’, zastanawiały mnie też małe liczby stojące za przychodami Microsoft 'z chmury’ co wyjaśniło się w arcie na CNBC, z którego wynika, że Office 365 jest chmurą .. .i nie jest równocześnie O_o . efekt jest taki, że pierwszy art zdaje pytanie czy MS będzie w stanie doścignąć niedościgniony AWS [wartość 14,6 mld USD], w drugim widać, że 'jeśli liczyć chmurę MS [wartość 6,8 mld USD] razem z Office 365 to wartość będzie 15,2 mld USD’. huh.

podobnie się czułem na prezentacji Archona na  Sysops/Devops gdzie przez pierwsze pół godziny nie byłem pewien o czym mówi… a chodziło to, że moje rozumienie chmury – bardziej PaaS i SaaS, rozmija się z projektami, o których mówił, gdzie aplikacje są budowane bardziej IaaS+docker. to była dobra lekcja (:

podsumowując – mówisz o chmurze, zacznij od kontekstu, czyli co przez to rozumiesz.

a na koniec trochę o ’Project Olympus’. jakoś do tej pory nie miałem okazji się z tym zderzyć a temat ciekawy. i znów pokazuje jak to świat stanął na głowie… to jest Open Compute Project – open source’owy projekt architektury data center, gdzie MS jest jednym z największych [największym?] kontrybutorem. i podczas gdy AWS, cytując z podlinkowanego artu:

We run our own custom-made routers, made to our specifications, and we have our own protocol-development team. It was cost that caused us to head down our own path, and though there’s a big cost (improvement)… the biggest gain is in reliability.

…w tym czasie MS staje się coraz bardziej integralną częścią open sourcowego świata, zarówno na poziomie dostosowywania swoich produktów do otwartych standardów, samego kodu źródłowego Linux i wielu aplikacji działających na tej platformie, aż po otwarte standardy hardware.

jest ciekawie.

eN.

 

kto ma licencję?

scenariusz

podczas migracji w hybrydzie jest taki dziwny moment, kiedy userzy są zawieszeni w dwóch środowiskach – onprem i online. skrzynki jeszcze onprem i czekają na swoją kolejkę do przerzucenia, ale już mają być włączone pozostałe usługi. zatem trzeba przypisać userom licencję z wyłączonym service planem dla Exchange Online – inaczej user będzie miał zdublowaną skrzynkę i część poczty nie będzie dochodzić [znaczy będzie, tylko nie do tej skrzynki co trzeba]. po jakimś czasie skrzynkę się migruje i włącza service plan dla usera. jest okres 3o dni 'grace period’ kiedy wszystkie usługi – czy to Skype fB czy Exchange – działają bez licencji, m.in. po to, żeby bez względu na czas migracji był okres przejściowy na zrobienie porządq.

może się więc zdarzyć, że ktoś przez przypadek nie będzie miał włączonego service planu i po 3o dniach straci dostęp do mailboxa. np. wywalił się skrypt, albo ktoś zapomniał przy jakiejś fali migracyjnej to zrobić… whatsoever.

zarządzanie licencjami póki co jest niewygodne – z niecierpliwością czekam na zarządzanie licencjami prze grupy – a na razie, to właśnie zarządzanie licencjami jest sporą niedogodnością. konstrukcja obiektów licencyjnych jest dość nieprzyjemna, moduły MSOnline i AzureAD totalnie się różnią, co oznacza całkowite przepisanie starych skryptów [albo używanie v1 – póki co nie zapowiadają, że zostanie wyłączona], łącznie z logiką….

kto nie ma licencji?

.. to aqrat mega proste…

  • połączyć się do Exchange Online
$o365creds=Get-Credential
$exchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $o365creds -Authentication "Basic" -AllowRedirection
Import-PSSession $exchangeSession -DisableNameChecking
  • połączyć się do AzureAD v2 [można i v1 – ale kod jest dla v2, trzeba mieć moduł AzureAD]
Connect-AzureAD -Credential $o365creds
  • i sam kod
Get-Mailbox|%{if( -not (Get-AzureADUserLicenseDetail -ObjectId $_.UserPrincipalName) ) { $_.UserPrincipalName } }

czego powyższa linijka nie wychwyci?

  • ktoś może mieć licencję, ale nie włączony service plan dla ExOL
  • ktoś może mieć licencję… np. na Project Online. i się nie wyświetli
  • skrzynki współdzielone nie potrzebują licencji

wyłączony service plan

a tu się zaczynają schody, bo trzeba zajrzeć do środka licencji. poniższy kod *nie jest skryptem* – to PoC, niechlujnie naskrobany na kolanie:

Get-Mailbox|%{$lic=Get-AzureADUserLicenseDetail -ObjectId $_.UserPrincipalName; if( -not $lic ) { write-host -ForegroundColor red "$($_.UserPrincipalName) - no license" } else { if(($lic.serviceplans|? serviceplanname -eq 'EX
CHANGE_S_ENTERPRISE').ProvisioningStatus -ne 'Success') { Write-Host -ForegroundColor Yellow "$($_.UserPrincipalName) - no ExOL service plan" } } }

co jest źle w powyższym kodzie?

  • sprawdzany service plan jest dla licencji E3 – trzeba sprawdzić jak się nazywają service plany i obsłużyć różne typy licencji. tutaj robocze założenie, że wszyscy mają taką samą licencję… i że jest to licencja w ogóle zawierająca Ex
  • wykorzystywanie 'write-host’ jako output jest dopuszczalne w roboczych sytuacjach, na szybko, ale jest bardzo złym zwyczajem w skryptach – trudno to potem obsłużyć, rozszerzyć, cokolwiek…

eN.

 

Send As w środowisq hybrydowym

scenariusz

przenosiny do o365 – codzienność. Hybryda Exchange – codzienność. teraz jak zaplanować migrację kont? alfabetycznie? a może lokalizacjami?

największym ogranicznikiem są uprawnienia dla skrzynek. w sfederowanej rzeczywistości nie wszystko jest przechodnie – uprawnienia nadane dla Exchange OnPrem niekoniecznie działają dla userów OnLine i vice-versa. oficjalny guide jest tu: https://technet.microsoft.com/en-us/library/jj200581(v=exchg.150).aspx . dla tego podstawowym wyznacznikiem powinny być skrzynki współdzielone, które powinny być przenoszone grupami -> skrzynka + wszyscy którzy mają do niej dostęp.

co do samego artu – pierwszą rzeczą, na którą warto zwrócić uwagę jest to, że dotyczy on wersji Exchange 2o13 i 2o16. niewprost jest zatem informacja, że Exchange 2o1o jest niewspierany. oficjalnie. ale nieoficjalnie działa tak samo – nie przetestowałem 1oo% przypadqw ale różnic nie widzę.

jest jednak ciekawe zdanie, na którym bym chciał się sqpić:

We don’t, however, support the use of the Send-As, Receive-As, or Send on behalf of mailbox permissions in hybrid deployments between on-premises Exchange and Office 365 organizations

z moich doświadczeń wynika, że jak najbardziej da się nadać SendAs dla dowolnej skrzynki. cały ambaras tkwi w tym, żeby uprawnienie nadać po dobrej stronie – tego DLA kogo są uprawnienia. zaraz pokaże na przykładzie.

jak to zrobić?

z tymi uprawnieniami to jest generalnie trochę namieszane – są aż 3 różne mechanizmy działając na różnych poziomach i do każdego jest inne polecenie. jest jak jest, i stało się tak, że jedna skrzynka jest lokalnie, druga zdalnie. co można zrobić?

środowisko:

  • testuser@w-files.pl jest na Ex 2o1o onprem
  • manager@w-files.pl jest zmigrowany do o365

przykładowe nadanie uprawnień dla skrzynki będzie wyglądało tak:

  • nadanie uprawnień Full Access, bo granularne nie działają. to uprawnienie działa na poziomie folderów w mailboxie.
Add-MailboxPermission -Identity 'testuser@w-files.pl' -User 'manager@w-files.pl' -AccessRights FullAccess
  • nadanie Send on Behalf. to uprawnienie zapisywane jest dla mailboxa.
set-Mailbox -Identity testuser@w-files.pl -GrantSendOnBehalfTo manager@w-files.pl
  • i na koniec uprawnienie Send As. to uprawnienie jest na poziomie obiektu Active Directory ponieważ wiąże się z delegacją uprawnienia. nie do końca rozumiem jak ten mechanizm jest obsługiwany przez Exchange, ale niewątpliwie informacja jest zapisywana dla obiektu AD. i tu jest clue dla działania SendAs dla hybrydy – ponieważ są dwa AD – OnPrem oraz OnLine, to najlepiej wykonać polecenie w obu, a na pewno musi być wykonane w AD, w którym jest obiekt korzystający z niego:
#sendAs in onprem Exchange:
#manager's mailbox is onLine so get-mailbox will not find it. 'name' or 'distinguishedaname' attribute has to be used as Identity
Add-ADPermission -Identity (get-mailbox testuser).name -User "CN=manager,OU=LogicUnion,DC=w-files,DC=pl" -ExtendedRights 'Send As'

#sendAs in OnLine Exchange:
#although testuser's mailbox in onprem, manager will query Azure AD for SendAs permission. below works!
Add-RecipientPermission -Identity testuser@w-files.pl -AccessRights SendAs -Trustee manager@w-files.pl

podsumowanie

no i działa.  a miało nie działać q:

eN.

 

 

office 365 – spojrzyj w przyszłość

office365 – jak zresztą wszystkie DevOpsowe zabawki – rozwija się bardzo szybko. czasem ciężko przygotować się do projektu bo nie wiadomo kiedy dana funkcjonalność się zmieni, pojawi lub zniknie. dodatkowym problemem jest to, że funkcje wdrażane są partycjami – i znów, coś co jest w GA dla jednego tenanta, może chwilę zając w innym…

a oto kryształowa, która przyszłość pokaże… office 365 roadmap

eN