Vlákno názorů k článku
Skype 4.2 a starší už v Linuxu nefunguje, uživatelé musí aktualizovat od Milan Keršláger - Microsoft nekoupil Skype, ale uživatele. Zbyla skořápka a...

Ja se ho zbavit nemuzu, protoze to v praci musime pouzivat :(

Chce to důsledněji ten shit sabotovat, ono se posléze někomu rozsvítí. :-)

Mě Lync nepadal - samozřejmě může být, že vám padá. Odkazy se kopírují buď z kontextového menu přes Copy Link, nebo z textu (pokud je na serveru vypnutá podpora hyperlinků). To "dementní" omezení délky zprávy je na 800 u první zprávy a 8000 u dalších zpráv - jde o chat, ten není na tapetování :). Ad-hoc call uděláte jednoduše tak že vyberete kontakty (klik, CTRL+klik) a z kontextového menu vyberete Start a Conference Call. Emotikony se v chatu běžně používají, ale pokud si píšete do chatu řekněme zdrojáky, může být dobrý nápad je prostě vypnout na serveru - je to na tři příkazy v PowerShellu (command line - to by se vám mělo líbit). Samozřejmě to jde nastavit i v každém klientu zvlášť. Formátování se resetuje stejně jako ve Wordu klávesou CTRL+Space.

Jak na to koukám, tam problém nebude v SW, ale v tom, že s ním neumíte zacházet. A teď si zkuste představit, co si lidé asi myslí o editoru vi :)

Kopirovat se da, ale strasne blbe to oznacuje(od verze 2013). Kdyz je link uprostred textu, tak se skoro neda to oznacit bez predchozicho radku. Proste to funguje hur nez v jakekoliv jine aplikaci. Na tom dementnim omezeni delky je nejhorsi to, ze se neda vypnout. O tech limitech samozrejme vim, ale nekdy mi pripada, ze to nezere ani tech 8000(i kdyz to neni prvni zprava). My tam netapetujeme, ale kolikrat potrebuju poslat treba stack trace vyjimky a musim to jako cu*** delit rucne. Nebo mi chces rict, ze je efektivnejsi psat e-mail? S emotikony je problem, ze si to musi nastavit druha strana. Jestli to ma byt urcene na praci(soudim dle integrace s outlookem a dalsimi moznostmi), tak proc tam vubec defaultne jsou? Na serveru to asi nevypnu, ve firme se stovkami zamestnancu jsou programatori pravdepodobne v mensine. O resetu formatovani jsem nevedel, diky za tip.
P.S. Ze mi pada asi nebude zpusobene tim, ze s tim neumim zachazet. Pri rekreacnim pouzivani to je mozna ok, ale ja na tom jedu cely den, mam tam treba deset konverzaci naraz, do toho nejake konference a ten soft to proste nezvlada a obcas vytuhne. Stalo se mi treba nekolikrat za sebou, ze mi chcipnul kdyz jsem oznacoval odkaz a omylem na nej pritom kliknul. Jenze kdyz jsem pak zkousel nasimulovat reprodukovatelny scenar, abych poslal bugreport, tak uz se mi to znovu nepodarilo.

Nejjednodušší je hodit do konverzace UNC path příslušného logu (alespoň u nás stack trace končí v logu). Samozřejmě můžete do konverzace hodit rovnou soubor pomocí drag&drop. Osobně ale většinou používám mail, protože pád aplikace je u nás dost výjimečná událost.

Pokud emotikony nejsou potřeba, tak byste neměl mít problém je vypnout v nastavení serveru. Pokud potřeba jsou, tak je to holt na programátorech. BTW neměl by být problém vypnout emotikony jen programátorům přes Group Policy. Buď je to v Office 2013 Administrative Templates (lync15.admx), nebo si .admx template můžete vyrobit sám.

Jak jsem psal, tuhnutí ani pády se u mě nevyskytovaly. Ale máte k dispozici Event Log i textový trace log v adresáři %USERPROFILE%\Ap­pData\Local\Mi­crosoft\Office\15­.0\Lync\Tracin­g. Samozřejmě se můžete kouknout v Process Exploreru, kde se thread zatoulal. A pokud jste vývojář, jistě máte při ruce debugger, víte že můžete vyrobit dump atd. BTW aplikace mohou mít problém i pokud máte nabouranou registraci nějakých COM komponent, nebo poškozené knihovny (včetně .NETu).

Mne se Lync 2013 chova hodne divne.

Pokud nekdo zapne video, zejmena u videokonference s mnoha lidmi casto zatuhne - prestane se prekreslovat okno a vypada jako by havaroval. pomoci klavesove zkratky Ctrl-Shift-P jde ale prepnout do compact view a zase se zacne chovat normalne.

Lync 2010 mi funguje fajn.

Takhle vypada chat na praci! https://www.hipchat.com/
Ne ta M$ sracka

Hm, a ten můžete mít plně na svých serverech? A umí skupinový video call, video prezentaci, voice, má integraci s ActiveDirectory a s Outlookem? Na tohle se zákazníci ptají :)

Zákazníci se hlavně ptají na to, jestli to vůbec funguje. Až potom přicházejí na řadu věci jako integrace s něčím.

OMFG, kdyby jsi na ten odkaz alespon kliknul ty pako, vsecho to maji napsane v H1

Takže zatím co já na (mnohdy fakt hloupé) otázky odpovídám, a většinou dost podrobně, vy mi raději napíšete obdobu "OMG RTFM". S takovou běžte do háje.

Nejsou to otazky, to co je hloupy. Nejsou to otazky. Krmis tady forum reklamou na sra*** od nejakyho nadnarodniho koncernu. Prosim moderatory, at daji na toho cloveka ban, to uz tu muzu cist reklamu na oriflame. Kazdej thread je hijacked, co uz se tu muzu dozvedet rozumnyho.
Mate z toho roote taky neco, nebo vas microsoft obchazi a dela aktivni protikampan na vasich forech zadamo?

Nikdy jsem na root nenapsal žádné reklamní sdělení. Samozřejmě mám nějaké názory na technické věci a nějaký světonázor - jako každý. Z příspěvků jiných lidí jsou také vidět jejich názory, nakonec proto je do diskuse píšou.

Na rozdíl od vás netoužím dávat lidem ban jen proto, že nesouhlasím s jejich názory. Naopak by mi hlídání "názorové čistoty" diskutérů přišlo jako dost nebezpečný trend.

Pokud se většina lidí ve firmě nemůže k nějakému systému půl hodiny přihlásit, zřejmě máte problém s dostupností toho systému. To je ovšem problém na serveru nebo na síti, který by vaši lidé měli řešit - nikoliv problém produktu (který se takhle běžně nechová). Totéž u ostatních popsaných problémů.

Pro srovnání: předpokládám že kdyby se půl hodiny lidé nedostali řekněme na intranetový portál, asi byste netvrdil, že použitý typ web serveru je špatný. Spíš byste věděl, že máte někde problém s konektivitou nebo správou serveru.

Chybu v kódu aplikace si tedy nepripoustite a tvrdíte, že je Lync bez chyby? To je docela odvaha ...

A vy víte, že se jedná o chybu v kódu aplikace? Pokud se půlka firmy nemůže přihlásit k serveru, je nejspíš problém v konektivitě, nebo ten server má nějaký problém. Tím problémem serveru může být neplánovaná odstávka, nějaký nedostatek místa, nebo cokoliv jiného.

Chcete nějaký podobně nesmyslný komentář? Tady je. "Nejde intranet? To bude jistě chyba v Apache serveru." :)

Lael přece ví vždy, že chyba je jinde než u MS produktů ;-), to mu nevysvětlíte, že když vše jede, jen jediný systém od MS se chová blbě, tak že to dle logiky musí být kde asi, on musí najít hromadu výmluv, proč to je určitě jinde a přitom o tom ví prd ;-)

Jo, to když vám nejede intranet postavený na Apache serveru, a všechno ostatní jde, zjevně musí jít o chybu v Apache serveru :). Pokud se - jak tu kolega popisoval - spoustě uživatelů nejde přihlásit na Lync server, na rozdíl od vás nevidím jediný důvod šmahem tvrdit, že je to chyba produktu. Asi to bude tím, že už mám na rozdíl od vás nějaký ten troubleshooting serverových produktů za sebou.

Přesně klasika... Když už vám docházejí argumenty co by asi tak mohlo být blbě všude jinde než na straně MS, tak začnete zpochybňovat odbornost diskutéra a prsit se svojí. Takže to vrátím na vaši stranu, ať jsme si kvit a už s váma dále nemám co diskutovat:
Vzhledem k tomu, že víte prdlačky jaký mám ma za sebou troubleshooting serverových a jiných produktů za sebou, tak jen jako vždy vaříte z vody a prostě šmahem odsuzujete cokoli, jen aby jste našel argument (ale jen pro ten argument), proč to určitě je jinde.
Kromě vaření z vody podsouváte ostatním, že řekli (napsali) co neřekli (nenapsali) a proto si myslím, že si diskutovat vystačíte sám, založte si vlastní vlákno (nejlépe na jiném serveru, tady jste trochu špatně), vymýšlejte si hypotetické argumenty a protiargumenty sám, uspokojte tím to co si tím uspokojujete a my ostatní budeme spokojení taky.

Naopak jsem neviděl žádný dobrý argument, ze kterého by plynulo, že jde o problém produktu. Samozřejmě chápu, že podle některých lidí musí jít vždy automaticky o chybu v produktu MS, protože proto :)

K tomu vaření z vody: pokud jsem si všiml, zatím tuhle techniku používáte vy. Možná čekáte, že vám každý poklepe na rameno a řekne "jo, jasně, je to od MS, takže automaticky musí být chyba tam". Nicméně jsou na světě i lidé používající zdravý rozum, takže vám to neprošlo.

Všechno co popisujete vypadá jako problém s výkonem serveru (snad s výjimkou toho výběru textu). Nevím jak jste implementovali - dost možná vám Lync jede na virtuálu s dynamickou pamětí, přetížených SATA discích a se špatnou konfigurací síťových karet, data jsou na přetíženém vzdáleném SQL Serveru, a Lync server používají stovky uživatelů pro videokonference :). Dost možná potřebujete zahodit odborníky kteří Lync implementovali, a najmout na to někoho, kdo to fakt umí. Firmy běžně používají Lync na většinu ne-mailové komunikace, a zpravidla bez problémů.

Nebo se můžete učit. Pro začátek vám Frank White vysvětlí pět nejčastějších problémů, a na TechNetu máte popis Lync Server 2013 Stress and Performance Tool. BTW pokud si myslíte, že s jiným SW to půjde bez učení, tak jste na omylu.
https://www.youtube.com/watch?v=ziuxm9nlKu0
http://technet.microsoft.com/en-us/library/jj945609.aspx

Dost možná potřebujete zahodit odborníky kteří Lync implementovali, a najmout na to někoho, kdo to fakt umí.

No pochopitelně, implementace toho shitu chce celý tým ocertifikovaných expertů M$. Možná se někdy někdo u MS ale náhodou praští do hlavy a rozbřeskne se mu natolik, aby se zamyslel nad tím, zda je normální, aby implementace instantního kecadla s hovory a videem vyžadovala několik serverů, přičemž samotná instalačka té hrůzy má 1,3GB, SQL server v to nepočítaje. Megakrám.

Jestli myslíte, že při deploymentu jiného SW pro videokonference určeného pro větší počet lidí se obejdete bez znalosti věci, tak jste na omylu. I tam budete potřebovat dostatek paměti, rychlé disky, QoS atd.

Rychlé disky? QoS? Co to ten MS vyvádí, že na SIPu nic takového nepotřebujeme?

Co vyvádí? No, tenhle Lync zázrak prostě vytvářel podobný megaloman, který má na svědomí Exchange. Ono je to i stejně velké. Absolutně nepochopitelné. Po dvoudenním studiu se nám to monstrum povedlo korektně zlikvidovat - k odinstalaci existuje 101stránkový dokument ve Wordu.

A vy máte na SIPu například historii konverzace po stovky či tisíce lidí za nevím jakou dobu zpátky, včetně příloh, s full textovým vyhledáváním? A kolik lidí vám přes ten SIP hovoří najednou, že nepotřebujete QoS? Ono když si pár lidí začne tahat z file serveru řekněme ISO image, a k tomu chcete plynulé video pro pár dalších lidí, tak to bez QoS moc nejde.

Mohl jste si všimnout, že Lync není jen textový chat. Je to také nástroj pro skupinový chat, audio a video konference, nahrazující použití klasických telefonů a video konferencí (hm, ty asi v ČR nejsou moc "klasické").

SIP potřebuje pro videohovor méně než 1 Mbps, pokud máte gigabitové sítě, tak to nebývá problém i bez QoS, pokud je nemáte, tak vám většinou QoS stejně moc nepomůže. QoS se hodí tak maximálně na WiFi a i tam to spousta WiFi hardwaru umí dělat automaticky.

Fulltextové vyhledávání v historii není zrovna běžně používaná vlastnost, navíc si to řeší jednotliví klienti.

Bandwidth pro video záleží na rozlišení a frame rate. Samozřejmě pokud vystačíte s obrazem 320x240px, kde horko těžko spočítáte kolik očí má ta čmouha na druhé straně :), tak se dostanete na poměrně nízký bitrate. U MS Lync se u peer-to-peer spojení dostanete typicky na 0.5Mbps, nejvýše na 4Mbps.
http://technet.microsoft.com/en-us/library/jj688118.aspx

QoS samozřejmě pomůže. Pokud máte 100Mbps síť, je to naprostá nutnost. Pokud máte 1Gbps síť, pomůže to v případě že vám po síti běží dva DB backupy, a k tomu si spousta lidí tahá soubory přes file sharing. Minimálně na serveru se vyplatí mít network offloading. Samozřejmě je rozdíl mezi síti s deseti uživateli a jednou aktivní chat session, a sítí s tisíci uživateli, stovkou aktivních chatů a několika video konferencemi.

Historie se drží na serveru - když se uživatel přihlásí na jiném stroji, automaticky se mu dotáhne. Drží se to v DB, a pokud server nemá dost paměti a dost rychlé disky, může se řada operací dost protáhnout. Lync je na rozdíl od podvojného účetnictví real time aplikace, takže je nutné sizing HW dělat trochu jinak.

Váš vysoce technicky erudovaný a věcný příspěvek - jistě založený na nějaké osobní zkušenosti - jsem vzal na vědomí :)