Fotos in Lync 2010 – In SharePoint MySite bearbeiten

3
198 Tage
by in Allgemein, Infrastruktur, Lync 2010, Lync Clients

Worum geht’s?

Die Integration von Lync und SharePoint bietet zusätzliche Möglichkeiten der Collaboration und eine Konsolidierung von Datenquellen. Ein wie ich persönlich finde sehr schickes Feature ist die Möglichkeit, Lync Benutzerfotos aus SharePoint via Active Directory zu importieren und anzuzeigen. DIe Grundlagen der Synchronisierung haben Nathan Winters hier und Damien Caro hier ausführlich beschrieben. Sobald diese Infrastruktur Voraussetzungen erfüllt sind, können Lync Benutzerfotos aus SharePoint via Active Directory angezeigt werden. Fein!

Wie kann ich nun dieses Foto ändern? Natürlich bietet sich die SharePoint MySite zur Editierung an. Dafür ist der Lync-Client tatsächlich vorbereitet, ich muss nur die Lync Bild Optionen öffnen. Diese lassen sich am schnellsten über einen Klick auf mein Foto erreichen.

 


 

Dort findet sich der URL-Link, der zur MySite führen soll. Aber trotz konfigurierter Synchronisierung zwischen Active Directory, SharePoint und Lync Server ist diese Link nicht aktiv. Warum ist das so?

Die Lösung

Nun, die Antwort erschließt sich nicht unmittelbar. Genau dieser Punkt wird in allen Blogartikeln, die ich recherchiert habe, erstaunlicherweise komplett ignoriert. Dabei halte ich genau diese Änderungsmöglichkeit für eine Komfortfunktion² und genau dies macht einfach noch mehr Spaß, Kunden in Produktdemos zu zeigen. :-)

Also, um auf den Punkt zu kommen, es ist eine Konfiguration auf dem Client notwendig. Die MySite URL muss als Link Provider in der Office 2010-Konfiguration des Benutzers definiert und in der Registry des Benutzers gespeichert sein.

[HKEY_CURRENT_USER\Software\Policies\Microsoft\office\14.0\common\Portal\Link Providers\MySiteHost]
“URL”=”http://mysite.domain.loc”
“DisplayName”=”MySite”

Die Dokumentation dazu ist natürlich auf der Technet zu finden, nur der Querverweis dahin hatte mir gefehlt. Kein Wunder beim Titel des Artikels. ;-) Darauf wäre ich nie gekommen, hätte ich nicht den Forenthread von Pernille Herold im Technet-Forum mit dem Titel I have set client policy to ShowSharepointPhotoEditLink=True and can see the link in the Lync client but it is pointing no-where. gefunden. Vielen Dank für diesen Beitrag, Pernille!!

So, mit diesen Informationen versorgt, leitet mich ein Klick auf den URL-Link auch tatsächlich auf meine MySite.

Fazit

Das ist wieder ein typischer Effekt, der nur da auftaucht, wo die Umgebung nicht vollständig so konfiguriert ist, wie vom Hersteller vorgesehen. Wäre die MySite URL in meiner Umgebung per Office Policy definiert worden, hätte das Feature In MySite bearbeiten out-of-the-box funktioniert und ich hätte das nicht recherchieren müssen. Nun ja, wieder einmal ein Erkenntnisgewinn durch Reverse Processing, oder so. :-)

Ich hoffe, das hilft jemandem weiter.

SQL Server Reporting Services – welcher Deployment Mode?

0
226 Tage
by in Lync Server, SQL

Worum geht’s?

Die Bereitstellung des Lync Monitoring Service setzt die Installation der SQL Reporting Services voraus (steht hier). Sofern SQL Server und/oder Reporting Services noch nicht bereitgestellt worden sind, taucht beim Setup gern die Frage auf, in welchem Mode die Reporting Services installiert werden sollen. Zur Auswahl stehen:

  • Native Mode
  • SharePoint integrated Mode

Zusätzlich gibt es noch eine Hybrid-Variante, den

  • Native Mode with SharePoint Webparts

Die Antwort auf die Frage nach dem richtigen Deployment Mode aus Lync-Perspektive könnte ganz einfach lauten: Native Mode, weil die Reporting Services Instanz dann exklusiv für Lync bereitgestellt werden kann. Aber worin unterscheiden sich die Modes, und wo macht der SharePoint integrated Mode vielleicht Sinn? Als Quelle dient dieser Artikel.

Native Mode

Im Native Mode ist eine Reporting Services Instanz ein Stand-alone Applikationsserver, der alle Funktionen von Anzeigen, Verwaltung, Verarbeitung und Übermittlung von Berichten und Berichtsmodellen bietet.

SharePoint integrated Mode

Im SharePoint integrated Mode muss eine Reporting Services Instanz innerhalb einer SharePoint-Serverfarm ausgeführt werden. Im Gegensatz zum Native Mode bietet hier eine SharePoint-Website den Front-End Zugriff auf Server Inhalte und Berichte. Dabei führen die Reporting Services als Back-End die Verarbeitung und Wiedergabe der Berichte durch.

Fazit

Sofern die Anforderungen für den SharePoint integrated Mode gegeben sind, kann eine SQL Reporting Services Instanz für den Lync Monitoring Service durchaus in diesem Mode betrieben werden. Ein Vorteil wäre dabei die nathlose Integration in eine SharePoint-Umgebung, mit den Vorteilen einer zentralisierten Designvorgabe und Berechtigungssteuerung.

Sofern die SharePoint-Farm darüber hinaus auch noch redundant und hinter Hardware Loadbalancern betrieben wird, würde sich dies sicherlich ebenfalls auf die Verfügbarkeit der Reporting Services auswirken. ;-)

Lync Server ForestPrep schlägt fehl

0
228 Tage
by in Active Directory, Lync 2010, Lync Server

Worum geht’s?

Wir haben als Ausgangsbasis eine alleinstehende AD-Domäne, in der OCS R2 ausgeführt wird. Diese Umgebung soll auf Lync aktualisiert werden. Gehen wir also davon aus, dass alle Infrastruktur Voraussetzungen erfüllt sind und der Planungsprozess abgeschlossen ist.

Bevor der erste Lync Server installiert werden kann, muss das AD in drei Schritten vorbereitet werden, was hier detailliert beschrieben ist. Dies ist natürlich aucbei er Aktualisierunge einer vorhandenen OCS-Umgebung der Fall.

Im zweiten Schritt der AD Vorbereitungen wird die Gesamtstrukturvorbereitung, das so genannte ForestPrep, ausgeführt. Dabei werden universelle Gruppen angelegt und globale Einstellungen vorgenommen, die von Lync Server verwendet werden.

Im heutigen Fall wurde ich mit einem Fehler beim Ausführen von ForestPrep konfrontiert, der erst einmal unverständlich erschien:

Fehler beim ForestPrep im Lync Bereitstellungsprotokoll

Fehler beim ForestPrep im Lync Bereitstellungsprotokoll

Mein erster Gedanke war: “Ich weiß, dass die Gruppen da liegen und schön, dass du sie gefunden hast. Warum ist das jetzt falsch?” Zugegeben, die Empfehlung “Specify where to create new Lync Server universal groups explicitly at the command line with the GroupDomain parameter.” klingt auf den ersten Blick nach einem guten Tipp (vgl. MS Technet). Doch ach, nicht in diesem Fall! Die Verwendung des CS PowerShell-Cmdlets

Enable-CsAdForest [-GroupDomain <FQDN of the domain in which to create the universal groups>]

ist hier nicht anwendbar, weil Lync Server nicht in eine andere Domäne installiert werden soll, als die vorhandene OCS R2 Umgebung. Daher bringt mir der GroupDomain-Parameter schlicht nüscht .

Die Ursache

Hach Leute, wäre doch alles so einfach wie das hier. Nun, die Ursache lautet: Die Gruppen liegen nicht im Standardpfad, den Lync bei der Gesamtstrukturvorbereitung erwartet, sondern waren im Vorfeld in eine andere OU verschoben worden.

Die Lösung

  1. Verschiebe alle RTC-Gruppen in den Standardpfad CN=Users,DC=domain,DC=tld
  2. Warte die AD-Replikation ab oder stoße sie manuell an.
  3. Führe die Gesamtstrukturvorbereitung für Lync Server erneut aus. Ob Setup Wizard oder CS PowerShell, ist egal.
  4. Warte die AD-Replikation ab oder stoße sie manuell an.
  5. Verschiebe alle RTC-Gruppen wieder zurück in ihre vorherige OU.

Wie sagte einer meiner Kollegen einst am Ende eines Supporttelefonats zum Kunden: “Danke, dass ich Ihnen geholfen habe.”

In diesem Sinne, horrido!

Konfigurieren von Lync Server 2010 Common Area Phones

0
313 Tage
by in Devices, IP Phones, Lync 2010, Lync Clients

Worum geht’s?

Lync Server 2010 bietet neue Funktionen für Lync IP Phones. Eine besondere Betriebsart für IP Phones ist die als Lobby-Telefon, oder auch Common Area Phone (CAP) genannt. Dieser Betriebsart widme ich mich in diesem Artikel.

Ich habe hier ein praktisches Beispiel für die Konfiguration von Lync für den Support von CAPs aufgeführt. Als Referenz dient dafür der MS Technet-Artikel MS Technet: Configuring Common Area Phones. den habe ich nicht vollständig umgesetzt, sondern mich auf das beschränkt, was mir für den Standardbetrieb sinnvoll erschien.

Alle Aktionen erfolgen unter Verwendung der Lync Server Verwaltungs-Shell. Shell-Aufrufe werden hier optisch umgebrochen, dürfen aber beim Ausführen keine Umbrüche enthalten! Wenn Sie Code übernehmen wollen, passen Sie diesen bitte gemäß Ihrer Lync Umgebung an.

Schritt-für-Schritt

Ein mögliches Vorgehen sieht demnach folgendermaßen aus:

Schritt 1: Erstellen und Konfigurieren eines neuen Kontaktobjekts für ein CAP

Erstellen

New-CsCommonAreaPhone -LineUri “tel:+4923194340780;ext=780″ -RegistrarPool “lspool.domain.loc” -OU “OU=Test-Accounts,DC=domain,DC=loc” -Description “Common Area Phone Test1″ -DisplayName “Common Area Phone Test1″ -DisplayNumber “+49 231 94340 780″

Konfigurieren

Set-CsCommonAreaPhone -identity “Common Area Phone Test1″ -DisplayNumber “0231 94340-780″

Schritt 2: Erstellen von Policies für CAPs

1. Client Policy

Client Policy definieren

Variante 1: Ohne Hotdesking

New-CsClientPolicy -Identity CAPohneHotDeskPolicy -EnableHotdesking $False

oder Variante 2: Mit Hotdesking

New-CsClientPolicy -Identity HotDeskPhonesPolicy -EnableHotdesking $True -HotdeskingTimeout 00:30:00

Client Policy zuweisen

Variante 1: Client Policy Ohne Hotdesking

Grant-CsClientPolicy -Identity “Common Area Phone Test1″ -PolicyName CAPohneHotDeskPolicy

oder Variante 2: Client Policy mit Hotdesking

Grant-CsClientPolicy -Identity “Common Area Phone Test1″ -PolicyName HotDeskPhonesPolicy

Client-PIN definieren

Set-CsClientPin -Identity “Common Area Phone Test1″ -Pin 943780

2. Voice Policy

Voice Policy definieren

New-CsVoicePolicy -Identity CommonAreaPhones -PstnUsages @{add=”LyncPUR”} -AllowSimulRing $True -AllowCallForwarding $True -Name CAPvoicepolicy -EnableDelegation $False -EnableTeamCall $False -EnableCallTransfer $False -EnableCallPark $True -Description “Test CAPs”

Voice Policy zuweisen

set-CsVoicePolicy -Identity CommonAreaPhones -EnableCallTransfer $True

 

Natürlich ist die hier gewählte Konfiguration nur eine Möglichkeit von vielen. Den gesamten Bereich der Konferenzfunktionen habe ich hierbei gar nicht berücksichtigt. Impulse dazu gibt wiederum die MS Technet.

Firmware Updates für Lync IP Phones

334 Tage
by in Audio Devices, Devices, Lync 2010

Worum geht’s?

Firmware Updates für Lync IP Phones können über den Client Update Service bereitgestellt werden, der auf einem Lync Front-End Pool ausgeführt wird. IP Phones prüfen beim Starten ihre Firmware Version gegen den Client Update Service. Ist eine höhere Version der Firmware auf dem Client Update Service vorhanden, führt das Device einen Download der Firmware durch und isntalliert das Update selbständig.
Wie kann ich nun Firmware Updates für meine IP Phones bereitstellen?

Schritt-für-Schritt

Actually, dies ist ein Vorgang in 7 Schritten
    1. Download des adäquaten Firmware Updates von der Update Resource Center for Lync Website
      Hier sind immer die aktuellsten Updates verfügbar. Außerdem besteht die Möglichkeit, einen RSS feed zu abonnieren.
    2. Lokales Ausführen der UCUpdate.exe Datei
      Dabei wird die UCUpdate.cab entpackt. Da alle Update Pakete für die verschiedenen Devices UCUpdate.cab heißen, empfiehlt es sich, diese in eine nach Hersteller und Modell sortierten Ordnerstruktur abzulegen.
    3. Hochladen des IP Phone Firmware Updates (mit Beispielpfad)
      Der folgende Befehl wird in der Lync Management Shell ausgeführt. Er besteht aus zwei Cmdlets, die gepipet sind. Das heißt, das Ergebnis des ersten Cmdlets wird dank der Pipe “|” an das zweite Cmdlet übergeben. Das ist in diesem Fall besonders sinnvoll, da somit alle Lync WebServer Instanzen in einer Lync Umgebung abgefragt und mit dem Update versorgt werden. Damit wird sichergestellt, dass das Update auf alle Front-End Server verteilt wird und diese Clients aktualisieren können. Der Beispielpfad muss natürlich angepasst werden:

      Get-CsService -WebServer | ForEach-Object {Import-CsDeviceUpdate -Identity $_.Identity -FileName “C:\Install\Lync 2010 Server\Updates\Phone Edition\UCUpdates.cab”}
    4. Definition eines Device als Test Device
      Firmware Updates, die auf den Client Update Service hochgeladen werden, stehen den Clients nicht sofort zum Download zur Verfügung. Dieser Sicherheitsmechanismus erlaubt das Testen von Updates auf ausgewählten Test Devices, bevor die Updates im Client Update Service freigegeben werden. Ein Test Device wird entweder mit seiner Seriennummer oder seiner MAC Adresse im Lync Control Panel konfiguriert. Beide Daten sind auf der Unterseite der IP Phones zu finden.
Definition eines Lync Test Device

Lync Test Device

  1. Neustart des Test Device
    Das Test Device führt den Updatevorgang durch und startet zum Abschluss selbständig neu. Der Vorgang dauert im Idealfall rund 10 Minuten.
  2. Prüfen der Firmware Version
    Nach dem selbständigen Neustart des Device lässt sich der Erfolg des Update Vorgangs leicht überprüfen. Öffnen Sie im Phone Menü den Eintrag System Information. In der ersten Zeile ist die Client Version aufgeführt. Diese sollte eine höhere Revisionsnummer aufweisen als vor dem Update, ist ja klar. ;-)
  3. Freigeben der Firmware
    Zuletzt erfolgt die Fregabe des Firmware. Hierbei achten Sie bitte neben der passenden Modellbezeichnung für Ihr Device (in meinem Fall Aastra 6725ip) auf die richtige Revision Ihres Device (zu finden auf dem Device unter System Information).

Freigeben eines Lync Device Firmware Updates

Achtung, geht los hier!

0
354 Tage
by in Allgemein

Moin zusammen, jetzt geht’s hier los. My UC-Diary bietet Tipps, Tricks und meine persönlichen Erfahrungen im Umfeld von Unified Communications (UC). Alles hier Veröffentlichte spiegelt meine persönliche Meinung und/oder meine persönliche Erfahrung wider und erhebt keinerlei Anspruch auf Richtigkeit und/oder Vollständigkeit. Die Verwendung hier veröffentlichter Codebeispiele und/oder Skripts erfolgt auf eigene Gefahr.

Also dann, viel Vergnügen.

Heiko Steinweg

Go to Top