Uruchamianie usług chmurowych w hybrydzie

Usługi czyli EXO (Exchange Online) i SOL (Skype for Business Online). Problem w hybrydzie polega na tym, że nie można skorzystać z interfejsu portal.office.com – należy konta założyć w środowisq onprem. i oczywiście prostą odpowiedzią byłoby skierowanie do commandletów Exchange i SfB w onprem… ale po co wtedy byłby wpis?

Scenariusz

zakładamy konto użytkownika i chcemy aby od razu miał skrzynkę w EXO i uruchomione usługi SOL. można założyć całość w onprem a potem migrować… ale to straszna strata czasu i wysiłq.

Standardowo

niemniej zacznę od standardowej metody, ponieważ tak to się robi oficjalnie.

po założeniu konta w AD, należy wykonać enable-RemoteMailbox – opis polecenia oraz doqmentacja do hybrydy. następnie trzeba włączyć konto SOL poleceniem enable-CSUser, a sztuczka polega na dodaniu parametru  „-HostingProviderProxyFqdn sipfed.online.lync.com”.

problem z tym rozwiązaniem jest taki, że żeby założyć konto potrzebne są aż trzy różne moduły: Active Directory, Exchange oraz Skype for Business. Prawidłowo administracja powinna być tak zorganizowana, że administratorzy logują się na stację zarządzającą, gdzie mają wszystkie narzędzia zainstalowane – w szczególności te wymienione. i oczywiście sugerowałbym aby tak to się odbywało. jednak… życie pisze własne scenariusze, np. taki, że jest sobie system HR, z którego wypływają dane o użytkownikach. i jak developer ma sobie z tym poradzić? do LDAP dość łatwo się dostać i są do tego standardowe biblioteki w samym frameworq, a do Ex czy SfB już tak różowo nie jest.

HACKED

….podam sposób, jak można założyć mailbox i włączyć SIP, wyłącznie przy pomocy modułu Active Directory/dostępu do LDAP. zaletą takiego rozwiązania jest brak konieczności instalacji pozostałych – i to właśnie był czynnik, który zmusił mnie do zrobienia takiego rozwiązania. zacznę od przestrogi:

zaprezentowane rozwiązanie nie jest wspierane, a konsekwencje użycia mogą być ciężkie do przewidzenia – dla tego przetestuj dokładnie, upewnij się, że rozumiesz co robisz i jak to działa tak, aby w razie co być w stanie naprawić. pełne commandlety wykorzystują mechanizmy sprawdzające poprawność ustawianych wartości, czy nie występują duplikaty w domenie, i wiele innych, których tutaj nie ma – a więc można namieszać. korzystasz na własną odpowiedzialność.

no to jak już się przestraszył[ae]ś, to teraz rozwiązanie.

w zasadzie najważniejszym trikiem jest zrozumienie jak działa hybryda – wszystkie zmiany wprowadzane są w onprem i synchronizowane do chmury. czyli wskazane polecenia – enable-RemoteMailbox czy enable-CSUser – wbrew temu co możesz sądzić, w żaden sposób nie łączą się z Office365. jedyne co robią, to modyfiqją wartości atrybutów w AD. w związq z tym można napisać skrypt, który dokładnie to zrobi.

nie będę zamieszczał całego skryptu – są w nim elementy specyficzne dla konkretnego klienta – ale wszystko co niezbędne znajdziesz poniżej.

Exchange

atrybuty, które należy zmodyfikować mogą się różnić, zależnie od klienta – wiadomo, różne firmy mają różne wymagania. poniżej zestaw atrybutów 'podstawowych’:

    $EXOattributes=@{
        'mail'=$oUser.UserPrincipalName
        'mailNickname'              =$oUser.SamAccountName
        'msExchPoliciesExcluded'    =@('26491cfc-9e50-4857-861b-0cb8df22b5d7') #disable automatic email address creation
        'msExchRecipientDisplayType'='-2147483642'
        'msExchRecipientTypeDetails'='2147483648'
        'msExchRemoteRecipientType' ='1'
        'msExchUMDtmfMap'           ="" 
        'msExchVersion'             ="44220983382016" #Ex2010 ; Ex13 = "88218628259840" ; Ex16 = "1125899906842624"
        'proxyAddresses'            ="" 
        'showInAddressBook'         ='CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=LOGICUNION,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=LOGICUNION,DC=LAB'
        'targetAddress'             ="SMTP:$($oUser.SamAccountName)@LogicUnion.mail.onmicrosoft.com"
    }

to, co widać powyżej, to oczywiście zestaw atrybutów obiektu User w AD, niezbędnych do założenia skrzynki.

  • mail: $oUser to obiekt użytkownika, pobrany wcześniej jako „$oUser=get-aduser <name> -properties *”. tutaj założenie jest, że podstawowy email jest taki sam jak UPN
  • mailNickname: standardowo jest taki sam jak SAM
  • msExchPoliciesExcluded: jeśli chcę ustawiać adresy email ręcznie to wskazana polisa (GUID taki sam dla każdego Ex) jest odpowiednikiem odznaczenia 'Automatically update email addresses…’ . jeśli adresy będą się wypełniały standardowymi polisami, to można pominąć
  • msExchangeRecipient*: wskazują na typ skrzynki. szczegóły tutaj. ogólnie – wskazuje, że skrzynka typu RemoteUserMailbox ma być założona
  • msExchUMDtmfMap: będzie za chwilę wypełnione – funkcja poniżej. de facto chodzi o konwersję na cyferki z cyferblatu telefonu, fragment UC.
  • msExchVersion: jest zawsze taka sama, i pochodzi z onpremowego Exchange. można sobie zweryfikować z jakimś lokalnym kontem
  • proxyAddresses: to oczywiście aliasy. jeśli ustawiamy inne niż podstawowy, warto nie zapomnieć wyłączyć polisy msExchPoliciesExcluded…
  • showInAddressBook: to CN list adresowych, w których ma się pojawić. tutaj standardowa lista globalna. ten CN można odczytać z innego użytkownika.
  • targetAddress: bardzo ważne pole, wskazujące na przekierowanie do chmury. na jego podstawie robiony jest routing do chmury na connectorze.

zmienna jest typu hashtable, można więc sobie powyliczać np. proxyaddresses, poustawiać co potrzeba. np. DTMF. funkcja, która konwertuje ciągi do DTMF:

function convert-str2dtmf {
    param(
        [char[]]$str
    )
    $dtmfCodes=@{
        "a"=2;
        'b'=2;
        'c'=2;
        'd'=3;
        'e'=3;
        'f'=3;
        'g'=4;
        'h'=4;
        'i'=4;
        'j'=5;
        'k'=5;
        'l'=5;
        'm'=6;
        'n'=6;
        'o'=6;
        'p'=7;
        'q'=7;
        'r'=7;
        's'=7;
        't'=8;
        'u'=8;
        'v'=8;
        'w'=9;
        'x'=9;
        'y'=9;
        'z'=9;
    }

    $dtmfOut=""

    foreach($letter in $str) {
        $letter=([string]$letter).ToLower()
        if($dtmfCodes.ContainsKey($letter) ) { $dtmfOut+=$dtmfCodes[$letter] }
    }
    return $dtmfOut
}

i fragment kodu, który ustawia DTMF:

    $dtmfEmail=convert-str2dtmf -str $oUser.SamAccountName
    $dtmfLNFN=convert-str2dtmf -str "$($oUser.sn)$($oUser.givenName)"
    $dtmfFNLN=convert-str2dtmf -str "$($oUser.givenName)$($oUser.sn)"
    $EXOattributes.msExchUMDtmfMap=@("emailAddress:$dtmfEmail","lastNameFirstName:$dtmfLNFN","firstNameLastName:$dtmfFNLN")

zmienna jest tablicą zawierającą zazwyczaj trzy elementy w zapisie DTMF – adres email [a w zasadzie nazwa użytkownika – bez domeny], nazwa użytkownika 'lastNameFirstName’ oraz 'firstNameLastName’. a więc wyliczam przy pomocy funkcji konwertującej i paqję do zmiennej $EXOattributes.

kiedy $EXOAttributes zawiera wszystko to, co potrzebne, pozostaje pchnięcie tego do AD. i tutaj piękno i prostota PS:

 Set-ADUser -Identity $oUser.SamAccountName -replace $EXOattributes

i już. atrybuty są wypełniane, zsynchronizuje się do o365, a ten podejmie odpowiednie działania – czyli założy skrzynkę.

SOL

całość wykonuje się analogicznie – buduję hashtable, który potem pchnę do AD, a poniżej niezbędne atrybuty dla Skype for Business Online:

    $SOLAttributes=@{
        'msRTCSIP-DeploymentLocator'    ="sipfed.online.lync.com"
        'msRTCSIP-FederationEnabled'    =$True
        'msRTCSIP-InternetAccessEnabled'=$True
        'msRTCSIP-OptionFlags'          ='257'
        'msRTCSIP-PrimaryHomeServer'    ='CN=Lc Services,CN=Microsoft,CN=1:1,CN=Pools,CN=RTC Service,CN=Services,CN=Configuration,DC=LogicUnion,DC=Lab'
        'msRTCSIP-PrimaryUserAddress'   ="sip:$($oUser.UserPrincipalName)"
        'msRTCSIP-UserEnabled'          =$true
    }

te zbudowane są dla środowiska sfederowanego, gdzie po stronie OnPrem stoi Lync 2o13. to może mieć znaczenie dla atrybutu msRTCSIP-PrimaryHomeServer – ponieważ nie wiem czy tak samo wygląda CN usługi SfB.

dla 'OptionFlags’ link z wyjaśnieniem wartości można znaleźć tutaj.

Set-ADUser -Identity $oUser.SamAccountName -Replace $SOLAttributes

zakończenie

jak wspomniałem, nie publiqję całego skryptu, ponieważ logika wyliczania czy to proxyaddresses czy innych elementów jest dla konkretnego środowiska i każdy musi sam to oprogramować. celem wpisu jest tak na prawdę pokazanie na czym polega 'od spodu’ założenie konta w EXO czy SOL w środowisq hybrydowym. niby każdy wie, że zmiany synchronizują się w jedną stronę, a jednak podczas rozmów, okazuje się, że wszyscy spodziewają się jakiejś dodatkowej komunikacji pomiędzy systemami. a tu nic takiego nie ma – jest tylko synchronizacja i tyle.

nie jest to zalecany sposób tworzenia… ale na pewno fajna zabawa (;

eN.

SkypeOnlinePowershell wywala się błędem o braku VC++ redistributable

exploruję tamat BOTów (super sprawa pod kontem obniżenia kosztów HelpDesk!) i aby zarejestrować BOTa w SfB dla tenanta trzeba zainstalować bohatera tytułowego – Skype for Business Online Connector. pomimo spełnienia wszystkich warunków (prerequisites), instalator wywala się z informacją, że brakuje VS C++ Redistributable. trochę się z tym pomęczyłem, nic nie udało mi się znaleźć na forach, więc trzeba grzebnąć samemu.

główny log nic powiedział, ale w logu *_TenantPowerShell.msi.txt jest coś takiego:

MSI (s) (08:10) [23:39:07:026]: Note: 1: 2262 2: Signature 3: -2147287038 
MSI (s) (08:10) [23:39:07:026]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64 3: 2 
MSI (s) (08:10) [23:39:07:026]: Note: 1: 2262 2: Signature 3: -2147287038 
MSI (s) (08:10) [23:39:07:026]: PROPERTY CHANGE: Adding PROPERTY_POWERSHELL_V51_INSTALLED property. Its value is '1.0, 2.0, 3.0, 4.0, 5.0, 5.1'.
MSI (s) (08:10) [23:39:07:027]: Skipping action: SetReinstallMode (condition is false)
MSI (s) (08:10) [23:39:07:027]: Doing action: FindRelatedProducts
Action ended 23:39:07: AppSearch. Return value 1.
Action start 23:39:07: FindRelatedProducts.
MSI (s) (08:10) [23:39:07:028]: Doing action: LaunchConditions
Action ended 23:39:07: FindRelatedProducts. Return value 1.
Action start 23:39:07: LaunchConditions.
MSI (s) (08:10) [23:39:09:307]: Product: Skype for Business Online, Windows PowerShell Module -- Skype for Business Online, Windows PowerShell Module installation or uninstallation requires that Microsoft Visual C++ 2017 x64 Minimum Runtime - 14.10.25008 Package is already installed.

no to już blisko rozwiązania… bo wskazana ścieżka nie istnieje. znalazłem wpisy od innych paczek VS redist i na tej podstawie zrobiłem nowy plik reg do obecnej wersji:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64]
"Version"="v14.16.27012.01"
"Installed"=dword:00000001
"Major"=dword:0000000e
"Minor"=dword:00000010
"Bld"=dword:00006984
"Rbld"=dword:00000001

instalator łyknął. gra i buczy (:

eN.

 

 

’Gorący ziemniak’ – Skype for Business

Disjoint Communications

usługi komunikacyjne dostarczane przez MS zawsze były w dużym dysonansie – z jednej strony całe linie hardware, integracja z komputerem – pełny VoIP i Video Conferencing… na ulotkach. z drugiej… masakra – kto konfigurował OCS czy Lync wie o co chodzi. masakryczny end-user experience z brakiem historii wiadomości w ramach klienta, kłopotami z synchronizacją książki adresowej czy kalendarza, ciężka konfiguracja sieciowa i integracja – zarówno z Exchange jak i centralkami VoIP. Unified Communication było świetną ideą, i nawet w kilq firmach widziałem to dobrze wdrożone i nieźle działające. ale praca przy projektach UC – huh. kamieniołomy. powoli, wraz z pojawieniem się Skype for Business, zaczynało to w miarę sensownie działać a SfB Online wszystko uprościł. ale oczywiście usługi SaaS nie są dla każdego…

Unified Intelligent Communication

aż tu nagle pojawia się Teams. niby narzędzie zupełnie nie związane, ale z jakiegoś powodu decydują się inkorporować SfB w Teams… przepisując kod. raczej korzysta się z gotowców i aplikacje wykorzystują wzajemnie swoje możliwości – te same biblioteki, czy DCOM, żeby nie pisać dwa razy tego samego. to było dość dziwne. efekt dość qriozalny – niby w Teams jest SfB ale wiadomości są zupełnie rozdzielne – wysłane w ramach Teams są tylko w Teams, wysłane via SfB są tylko w .. skrzynce Exchange. od jakiegoś czasu chodziła plotka, że Teams przejmie tą funkcjonalność, ale trochę nie chciało mi się wierzyć… aż tu takie newsy:

wygląda to na niezłą rewolucję w grupach projektowych…

jest kilka takich produktów, które przeszły ciężką drogę w ramach MS, niektóre jej nie przeżyły – jak rodzina 'forefront’, do której zaadoptowany został MIIS stając się na chwilę FIMem, żeby przetrwać jako jeden z nielicznych jako MIM. to chyba na razie rekordzista w ilości nazw produktowych [MMS -> MIIS -> ILM -> FIM -> MIM]. usługi VoIP/Video zdają się doganiać [LCS -> OCS -> Lync -> SfB -?Teams?].

ciekaw jestem jak to będzie wyglądało? jeśli nie będzie 'cienkiego klienta’ – cienkiego w porównaniu do Teams, które przecież mają dużo szersze zastosowanie – to usługi takie jak 'presence’ czy IM będą mało wygodne. w sumie 'presence’ jest w dowolnym miejscu – czy to outlook, czy SharePoint. a IM? zostanie przerzucone do Teams czy do Outlook? huh. decyzja biznesowo wyjaśnialna, ale dla firm i dla użytkownika końcowego, to będzie gruby bałagan. przestawienie się z 'klienta IM i konferencji Video’ na 'aplikację do pracy grupowej’ nie będzie proste…

…ale przecież nie tak dawno pisałem, że wyobrażam sobie, żeby w projektach MS Teams stało się jedynym wykorzystywanym narzędziem. a zatem czekam na łzy grupy projektowej Exchange (;

gorący ziemniak

w sumie to mam więcej pozytywnych emocji o tej decyzji, bo mam wrażenie, że SfB, podobnie jak MIM, to takie gorące ziemniaki, które niby potrzebne, ale nikt ich nie chce i nie do końca wiadomo co z nimi zrobić, więc podrzuca się je do następnego w kolejce. sam produkt dostarcza bardzo fajną funkcjonalność, ale to za mało na samodzielność. więc są adoptowane tam, gdzie podąża w danym momencie trend – a teraz jest hype na Agile i Grupową Komunikację [znowu].

boję się tylko tego, że o ile MS Teams jest świetnym produktem do małych projektów i można go już semi-produkcyjnie używać, to jest masakrycznie niedojrzały. mam nadzieję, że transformacja potrwa wystarczająco długo i spokojnie, żeby zdążył stać się w pełni przemyślanym narzędziem, bo inaczej wyjdzie z tego olbrzymi 'szwajcarski scyzoryk’ – niby super, z tysiącem gadżetów, ale kto chce nosić takie bydle w kieszeni?

eN.

eN.

URI PowerShell dla Skype Online

PowerShell zarówno dla Exchange jak Skype Online dostępny jest poprzez stworzenie sesji WinRM i zaimportowanie zdalnych komend. prosta komenda połączenia do SkypeOL to po prostu:

$sfboSession = New-CsOnlineSession -Credential (get-credential)
Import-PSSession $sfboSession

…ale ja jakoś od zawsze trafiam w nietypowe przypadki [środowiska] i połączyć się nie mogłem, ponieważ DNS nie wskazuje jeszcze na środowisko, do którego się chcę połączyć. po przeczesaniu internetów wszędzie trafiałem na 'pomoc’ aby dopisać parametr -OverrideAdminDomain “my.domain.365” . bezwartościowa, ponieważ tak jak pisałem, DNS nie jest jeszcze skonfigurowany. ale jest jeszcze jeden parametr, tym razem bardziej pomocny: -OverridePowershellUri . tylko to URI trzeba znać.

trzeba odpalić przeglądarkę na jakimś komputerze z DNS ustawionym na zewnątrz i wpisać: https://sched.lync.com . po uwierzytelnieniu zostaniemy przekierowani na URI dla naszego tenanta np: „https://webdir1f.online.lync.com/Scheduler/?AuthCookieName=RtcAuth” . dla PS będzie to: „https://webdir1f.online.lync.com/OcsPowershellLiveId”.

trochę wchodzenie przez komin, ale czasem trzeba pokombinować (; jak ktoś zna prostszy sposób to się proszę pochwalić.

eN.

Skype for Business bez DNS

trafiłem na ciekawy 'ficzer’ SfB, który jest bardzo przydatny podczas labów, ale może się przydać również podczas debugowania problemów.

Jak wiadomo, klient Skype for Business korzysta z odpowiednich rekordów DNS w celu zlokalizowania serwera, do którego ma się połączyć. jest fajny art, który pokazuje na diagramie sposób odpytywania.  nigdzie jednak nie znalazłem informacji, że w celu optymalizacji połączenia, tworzony jest plik cache: $env:USERPROFILE\AppData\Local\Microsoft\Office\16.0\Lync\<userSIP>\EndpointConfiguration.cache .

nie znalazłem scenariusza, w którym ten plik jest usuwany i ponawiane jest odpytywanie DNS. to ma ciekawe konsekwencje. klient łączy się bez DNSów! nie musiałem nawet odpalać network monitora – ustawiłem na lokalnej sieciówce DNS na 127.0.0.1 i odpaliłem SfB. działa (:

może to mieć pozytywne i negatywne efekty. negatywny może być wtedy, kiedy używa się lokalnego serwera SfB i dokona się zmiany adresów. nie wiem jak się zachowa, bo nie testowałem – zakładam, że ktoś to przemyślał, i jeśli nie może znaleźć wpisu z cache, sfailuje na zapytania DNS. ja natomiast, w nietypowym środowisq, przetrzymując dwa pliki cache, nadgrywam go zależnie od tego, co chcę testować i voila! mogę bez DNS łączyć się do odpowiedniego serwera, pomimo braq wpisów w DNS.

eN.

tajemniczy Skype

zakładam, że historii Skype specjalnie nie trzeba przedstawiać. najważniejszy [do celów tego wpisu] jest fakt, że został qpiony w maju 2o1o przez Microsoft, a od lat MS rozwijał własny produkt – wtedy jeszcze nazywany Office Communication Server. pomimo, że oba produkty są [m.in.] klientami VoIP, ich architektura działania jest totalnie inna…

… no właśnie – jest, czy też może 'była’? po zaqpie Skype długo wydawało się, że nic się nie dzieje. powiedziałbym, że 'bardzo długo’, albo wręcz 'za długo’. wynika to z totalnie różnych założeń obu systemów – OCS/Lync to produkty zorientowane na centralne zarządzanie, wykorzystanie w Enterprise, możliwość archiwizacji, wymuszenia zgodności z polityką firmy i prawem, własnością intelektualną itd. Skype przeciwnie – był aplikacją zorientowaną na rozproszenie, w architekturze hybrid P2P, z nastawieniem na zachowanie prywatności. no i jest protokołem w pełni zamkniętym. co prawda próbowano zrobić reverse engineering i można znaleźć jakieś tam opisy działania, ale to bardziej na poziomie ogólnym.

w tym samym czasie nastąpił boom na rozwiązania chmurowe, OCS zmienił się najpierw w Lync 2013, potem zforkował się w Skype for Business 2o15 oraz Skype for Business Online z office365.  zmiana nazwy nie była przypadkowa. Lync przesunął się w kierunq Skype, a Skype w kierunq Lync. co to oznacza?

najciekawsze jest owo 'przesunięcie Skype’. co prawda nadal nie ma opisu architektury rozwiązania, ale pewne rzeczy widać, i można pobawić się w dodawanie:

  • lista kontaktów jest już zintegrowana z outlook.com . nawet jeśli ktoś nie założył wprost konta 'outlook.com’ czy 'hotmail.com’ i loguje się użytkownikiem z innej domeny, to tak jest. ja np. loguję się loginem @gmail.com, żeby odebrać maila wysłanego na @outlook.com (;
  • Skype przeszedł na protokół MSNP24 na początq 2o14
  • pojawiło się sporo dodatkowych opcji, które nie były możliwe do zaimplementowania przy architekturze hybrid P2P..

polecam bardzo fajny artykuł, wyjaśniający zmiany, jakie zaszły 2o15-2o16 z tym produktem. najciekawsze cytaty:

“The original genius of Skype is that it was a peer-to-peer solution, which made sense in the early days of broadband, when everyone used a PC,” Microsoft vice president Gurdeep Pall told me recently. “But over the past 10 years, things have changed, and we now use multiple devices, where syncing state from device to device becomes challenging.”

“A couple of years ago, we started on a massive engineering project to transition Skype to a cloud-based solution,” Pall told me. “And much of what you’ve seen as new features in Skype, especially over the past year, has been connected to this new architecture.” This includes such things as audio and video chat, file sharing, photos and file sharing, offline access, Skype translator, bots, and more, he said.

…no i git. wszyscy szczęśliwi… [?]

bo jak się tak zastanowić, to co to oznacza dla wstępnych założeń funkcjonowania Skype? nie jest to już klient P2P, tylko prawie-Skype-for-Business. z centralnym zarządzaniem kontami, polisami… [archiwizacją i monitoringiem?]

nie żebym miał z tym jakiś problem. w sumie to przewidziałem to zaraz po pojawieniu się office365 q: niemniej pozostaje ciekawostką wartą zastanowienia zwłaszcza, jeśli ktoś kierował się korzystaniem ze Skype ze względu na zalety P2P lub ma po prostu dylematy związane z tym 'gdzie są moje dane i kto może je oglądać’. tym bardziej, że o ile architektura Skype for Business 2o15 jest dostępna i można dokładnie się przyjrzeć co i jak i jakie są schematy komunikacji, o tyle Skype nadal pozostaje owiany mgiełką mistycyzmu. poza kwestiami prywatności dochodzą problemy z wyznaczeniem wymagań sieciowych – bo nie ma oficjalnych informacji o schematach komunikacji takich, jak są dla linii biznesowej. można się tylko domyślać, że nawet jeśli nie dziś, to za chwilę, jedyną różnicą pomiędzy oboma produktami będzie 'otoczka integracyjna’, może jakieś dodatki korporacyjne jak możliwość integracji z własnym PBX. bo czemu niby nie miałbym widzieć 'presence’ w OneDrive [zarówno prywatnym czy biznesowym], dla doqmentu opublikowanego przez inną osobę prywatną? w końcu Skype for Web jest już inkorporowany w outlook.com i jest coraz większa integracja pomiędzy Skype a SfB…

eN.

Microsoft Skype

w sieci aż gorąco od informacji o planowanym zaqpie Sype przez Microsoft. najlepszy news jest na blinq i przedstawię najważniejszy cytat:

Skype will support Microsoft devices like Xbox and Kinect, Windows Phone and a wide array of Windows devices, and Microsoft will connect Skype users with Lync, Outlook, Xbox Live and other communities. Microsoft will continue to invest in and support Skype clients on non-Microsoft platforms.

zastanawiam się jak będzie wyglądać integracja Skype i Lync. obecnie dwoma podstawowymi zarzutami dla Lync są:

  • bardzo skomplikowany interfejs video-konferencji [dawne LM] dla użytkownika
  • brak komunikacji z innymi platformami voice – np. właśnie ze Skype.

mam nadzieję, że szybko uporają się z transportem pozwalającym na dzwonienie do userów skype z poza korporacji – Lync jest bardzo ukierunkowany na środowisko korporacyjne a to by go mocno otworzyło na świat. nie wspominając o tym, że kolejna usługa dochodzi do konsoli, co o kolejny kroczek zmniejsza potrzebę posiadania komputera w domu (;

drugim ważnym aspektem, na który trzeba zwrócić uwagę, to wyznaczenie samego kierunq działania – eMeS jest mocno spóźniony w kwestii urządzeń mobilnych [bardzo-pierwsza wersja Windows Phone 7, brak systemu na tablety zapowiadane dopiero na koniec przyszłego roq itd]. ostatnio poczynione zaqpy – związek z nokią i zaqp skype – pokazuje, że nie mają zamiaru się poddać. Lync jest bardzo dobrze ocenianym produktem i przy integracji ze skype może zabrać Cisco kawałek rynq VoIP, a nowe nokie z WP7 mogą okazać się ciekawą alternatywą dla starzejącego się iphone [bo na pewno nie dla androida q: ]

eN.