Skype for Business Delegates entfernen (bei einem Enterprise Pool) ohne Sefautil

Hi an alle, ich hatte die Tage den Fall, dass in einer Skype for Business OnPrem Umgebung ohne Enterprise Voice die Stellvertreter out Outlook/Exchange nach Skype for Business synchronisiert wurden (Exchange Delegate Sync in der CSClientPolicy aktiviert).

Leider gibt es hier einige Einschränkungen seitens MS was die Anzahl der Stellvertreter und vor allem die Anzahl der Delegatoren angeht (und das Ganze ist dann auch noch Client abhängig). Was in dieser speziell Situation beim Kunden dazu führte, dass die Stellvertreter aus Outlook/Exchange zwar in die Skype for Business Stellvertreter eingetragen wurden, allerdings nicht entfernt wurden sobald die Stellvertreter in Outlook entfernt wurden.

https://support.microsoft.com/en-us/help/3043678/lync-2013-and-skype-for-business-2016-users-are-prompted-with-you-have

Die Verwaltung dieser Stellvertreter lässt sich auf Seiten Skype for Business auch mit dem SEFAUTIL tun (Artikel folgt). Allerdings ist dass nicht in allen Umgebungen möglich, da dieses Tool Vollzugriff auf das SQL Backend benötigt, was bei unterschiedlichen Teams und Richtlinien unter Umständen schwierig werden könnte.

Es gibt einen (offiziell nicht supporteten) Weg diese Stellvertreter direkt in der Datenbank auf dem Frontend Server zu entfernen.

Als erstes muss der primäre Frontend Server des Delegators ermittelt werden mittels get-csuserpoolinfo <Sip Adresse des Delegators>

In der RTCLOCAL SQL Instanz auf dem primären Frontend Server in der Datenbank RTC gibt es eine Tabelle Resource im dbo schema. Hier ermittelt man die ReourceId des Delegators und des zu entfernenden Delegaten mittels SQL Abfrage.

Danach kann man in der selben Datenbank in der Tabelle Delegate im dbo Schema seine Stellvertreter ermitteln mittels SQL Abfrage.

Schlussendlich wird dann in dieser Tabelle der Datensatz mit der entsprechenden DelegateId mittels SQL Abfrage entfernt. Die SQL Abraten sind bei den SQL Objektname Case Sensitive!

Ein kleines Beispiel:

UserA (usera@company.com) hat User B (userb@company.com) als Stellvertretung in Outlook eingerichtet. Dies wird nach Skype for Business synchronisiert. Nun entfernt User A die Stellvertretung aus Outlook wieder, allerdings wird das Entfernen nicht nach Skype for Business synchronisiert.

  1. get-csuserpoolinfo sip:usera@company.com
    Das Ergebnis liefert Identity (UPN des Users), PrimaryPoolFQDN (Skype for Business Pool des Users), PrimaryPoolMachinesInPreferredOrder (hier ist der erste Eintrag der wichtige!) und einige andere Informationen.
  2. Man verbindet sich via SQL Management Studio oder SQLCMD auf den ersten Server auf die Instanz RTCLOCAL
    SQLCMD -S <erster Server FQDN>\RTCLOCAL
  3. nun wird die Id des Delegators ermittelt
    select * from rtc.dbo.Resource where UserAtHost = „usera@company.com“
  4. nun wird die Id des Delegates ermittelt
    select * from rtc.dbo.Resource where UserAtHost = „userb@company.com“
  5. nun ermittelt man die Liste der DelegateIds für User A
    select * from rtc.dbo.Delegate where DelegatorId = <Ergebnis aus 3>
    und schaut ob das Ergebnis aus 4 (die ID des Delegaten) enthalten ist
  6. nun löscht man diesen Delegaten aus der List
    delete from rtc.dbo.Delegate where DelegatorId = <Ergebnis aus 3> and DelegateId = <Ergebnis aus 4>

Jetzt ist User B in Skype for Business nicht mehr als Stellvertreter eingetragen.

Ich hoffe das hilft Euch ein wenig weiter.

Viele Grüße

Rouven

Lync/S4B Server Updates installieren

Hallo an alle,

heute möchte ich kurz beschreiben wie der Update Prozess einer Lync/S4B Umgebung aussehen kann. Normalerweise wird alle 3 Monate ein Cummulative Update (CU) bereit gestellt. Also ein Paket mit den „gesammelten Werken“, welche nicht auf ein vorheriges Update, sondern auf die RTM Version aufbaut, d. h. alle Updates von vorherigen CUs sind im aktuellen CU enthalten.

Welche Voraussetzungen sollten geschaffen werden?

Das Wichtigste ist wohl zu wissen, welche Server/Komponenten von dem Update betroffen sind. Dieser Beitrag beschreibt die Update Installation der Lync/S4B Server Komponenten via LyncserverUpdateInstaller.exe

Die verfügbaren Updates findet Ihr hier: https://technet.microsoft.com/de-de/office/dn788954.aspx

Die im LyncserverUpdateInstaller enthaltenen Updates betreffen alle Komponenten der Topologie mit installierten Lync/S4B-Funktionen (je nach enthaltenen Updates ist ein Paket ggf. nicht für jeden Server erforderlich).

Das bedeutet, dass alle Server mit Lync/S4B Rollen/Funktionen geprüft werden müssen. Darunter fallen auch SBAs, Persistent Chat und Edge Server!

RTFM!

Bitte vor einer „blinden“ Installation Abhängigkeiten zu anderen Produkten überprüfen und sich über enthaltenen Neuerungen informieren. bei Audiocodes wäre das z. B. ein GUI Update, welche vor dem Lync/S4B Update gemacht werden soll/muss, wie hier erklärt.

Was passiert bei einem Update in der Regel?

Ein CU aktualisiert die Logik der entsprechenden Lync/S4B Rollen und in einigen Fällen auch das Schema der Backend Datenbanken (relevant für die Replikation des CMS!!!). Dies bedeutet für uns wir haben folgende 2 Schritte im Rahmen einer Updateinstallation.

1) Patchen der Rollen
2) Update der Backend DBs

Da wir in den Voraussetzungen schon ermittelt haben, welche Komponenten von den Updates betroffen sind und welche Abhängigkeiten bestehen, ergibt sich hieraus normalerweise diese Abfolge:

1) Patchen der Lync/S4B Rollen auf allen Servern
2) Aktualisierung der Backend Datenbanken

Let’s Patch!

Aktualisieren der Lync/S4B Rollen

Um festzustellen, ob ein Lync/S4B Enterprise Pool „patchfähig“ ist, sollte man das Powershell CMDLet get-CSPoolUpgradeReadinessState ausführen. Der Output informiert über den aktuellen Zustand des Pools bezüglich einer Aktualisierung (mein Screenshot ist nicht aussagekräftig!). Diese Abfrage ist bei einem Standardedition Server nicht nötig!

14_PoolUpgradeReadinessState

Exemplarisch zeige ich hier die Aktualisierung der Lync/S4B Rollen an einem System. Dieser wird i. d. R. einmal für jedes Lync/S4B System in der Topologie durchgeführt.

Nach erfolgreichem Download des entsprechenden CUs auf den Server, startet man die Installation als Administrator.

09_Launch_CU

In dem sich öffnenden Fenster, sient man nun die enthaltenen Einzelupdates (nur die relevanten) mit Versionsnummer und die bereits installierte Version. ein kleines Symbol zeigt ob das jeweilige Einzelupdate erforderlich ist für das System.

10_InstallAction

Über den Button „Install Updates“ lässt sich nun die Installation starten. für die Einzelupdates, welche im Updatepaket eine neuere Version bieten. Ein entsprechendes Statusfenster informiert über den aktuellen Status der Installation.

11_InstallState

Wenn die Installation erfolgreich abgeschlossen ist, kann man die Übersicht (alle Versionen sind nun aktuell) mit einem Klick auf „Close“ schliessen.

12_Finish_Install

Nach der Installation sollten die Protokolle noch gesichtet werden, um zu sehen ob, bzw. was nicht korrekt aktualisiert wurde und ggf. wieso.

13_ReviewLogs

Es wird eine Datei für das CU und eine Datei für jedes Einzelupdate  generiert.

Nicht jedes Update benötigt einen Reboot der Maschine(n). Allerdings hat (zumindest mir) die Erfahrung gezeigt, dass es doch sinnig ist die Maschine(n) nach erfolgreicher Aktualisierung zu rebooten.

Aktualisieren das Datenbank Schemas

Dieser Schritt wird einmal in der Topologie für den CMS, Monitoring, Archiving und Persistent Chat durchgeführt.

Via Powershell bzw. ManagementShell wird das CommandLet Install-CSDatabase -ConfiguredDatabases -SQLServerFQDN <StandardEdition Server/SQL Backend für EnterprisePool> ausgelöst. Bei angepassten DB Pfaden oder benannten Instanzen müssen noch weitere Parameter „gefüttert“ werden. Gerne auch mit
-verbose um zusätzliche Informationen zum Aktualisierungsstatus zu erhalten.

14_UpdateDatabase

Nach erfolgreicher Aktualisierung habt Ihr es nun also geschafft. Herzlichen Glückwunsch!

 

 

Viel Erfolg!

Audiocodes SBA GUI Update Framework Error

Hallo an Alle,

kürzlich habe ich einige Audiocodes SBAs bei einem Kunden aktualisiert und folgenden Fehler erlebt.

Nach Audiocodes Vorgabe habe ich erst das GUI Update von Audiocodes installiert, um danach den Fehler zu erhalten, das eine Eigenschaft TargetFramwork nicht valide ist.

Nach einigen Tests und Recherche hier nun ein kurzes HowTo wie man das installieren und fixen kann. Ich habe nicht getestet ob, sich der Application Pool auch vor dem Update umstellen lässt und dann alles sauber durchläuft. Dies liefere ich ggf. in Kürze noch nach.

Installation des Updates:

Als ersten Schritt laden wir das aktuell GUI Update für die WebGUI unserer SBA von Audiocodes herunter. Dies bekommt Ihr nach Anmeldung (und nur mit gültigem Supportvertrag!) hier: http://www.audiocodes.com/downloads

Der erste Schritt ist nun mit einem unterstützten Browser auf die Webschnittstelle der SBA zu navigieren, um die aktuelle Version fest zu stellen.

01_Start

Wenn diese nun niedriger ist als die heruntergeladene Version wissen wir also, dass eine Aktualisierung nötig ist.

Die Aktualisierung wird nun ebenfalls über die Website der SBA durchgeführt. man meldet sich mit einem berechtigten Account an, navigiert zu Tools (1) auf der Linken Seite (Navigationsleiste), darin wählt man System Update (2). In dem PopUp Fenster hinterlegt man die heruntergeladene Datei (3) und mittels Klick auf „Apply“ übernimmt man das Update bzw. installiert es (4).

03_Upgrade

Nach einer kurzen Zeit wird man aufgefordert, dass das System einen nun abmeldet und die GUI aktualisiert wenn man auf „Apply“ klickt.

04_Apply

Nach dem Hinweis, dass das System nun aktualisiert kommt leider die Fehlermeldung, dass die Eigenschaft targetFramework=“4.0″ in der Web.config Datei nicht valide ist.

05_Error

Lösung des Problems:

Man verbindet sich via RDP, Monitor oder Console auf den Desktop der SBA und stellt, kurz gesagt, die .NET Framework Version des Application Pools im IIS für die Verwaltungswebsite von V2.0 auf V4.0.

Hier die detaillierten Schritte:

Im IIS Manager auf der SBA wir die Website lokalisiert (1.) und in den Basic Settings ermittelt um welchen Application Pool es sich handelt (2.).

06_Determine_AppPool

Im nächsten Schritt, wird in dem entsprechenden Application Pool die .NET Framework Version auf Version 4.0 eingestellt. Dies erreicht man im IIS Manager unter Application Pools (1.), dort den entsprechenden Application Pool auswählen, der im obigen Schritt ermittelt wurde (bei mir sba) (2.), dann in den Basic Settings (3.) die Framework Version ändern und mit nem Klick auf OK bestätigen (4.). Durch diese Änderung wird der Application Pool automatisch „recycled“ und die Seite kann aktualisiert werden im Browser.

07_Change_IIS

Et Voià! Die Website der SBA funktioniert wieder und die korrekte Version ist bereitgestellt.

08_Fertig

 

Viel Erfolg!

Rouven

 

Calls Blocken via MSPL Scripting

Hallo an alle, heute ergab sich die Anforderung bei einem Kunden Anrufe von einer bestimmten Nummer zu blockieren. Diese liess sich auf Gateway Seite nicht so einfach realisieren. MSPL Scripting war die Lösung dann doch greifbar. Mit diesen Skripten kann man den Lync/SfB Server um Routing/Funktionen erweitern. Schlussendlich kann man hiermit SIP Nachrichten Filtern/Manipulieren/Routen und einiges mehr. Die Syntax hierzu findet Ihr hier: https://msdn.microsoft.com/en-us/library/gg439378.aspx

Hier nun also zu unserer Anforderung: Audio Calls einer bestimmten Absendernummer blocken. Ein MSPL Script ist folgendermassen aufgebaut: Es gibt eine Manifest Datei mit der Endung .am in der Struktur einer ordinären XML Datei. der Header sieht ungefähr so aus:

<?xmlversion="1.0"?>
<lc:applicationManifest
Hier muss man lediglich das appUri (Namespace Attribut für sich anpassen (aus die Case Sensitivität achten ;-)), diese wird nach im Application Deployment auf der Lync Plattform noch benötigt.
Nun kann man noch die Anfragen und Antworten Filtern:
<lc:requestFiltermethodNames="ALL"strictRoute="false"
    registrarGenerated="true"domainSupported="true"/ >
<lc:responseFilterreasonCodes="ALL"/>
Hier hat man die Möglichkeit nach ALL, NONE oder Komma getrennt Methoden bzw. Reason Codes anzugeben.
Ein sehr wichtiges Attribut ist das folgende:
<lc:proxyByDefaultaction="false"/>
hier wird bestimmt ob Nachrichten die nicht durch unsere Logik laufen von Lync/SfB geproxied werden (true, wie sonst auch) oder nicht (false, also gedroppt werden).
Damit wir die zu blockenden Absendernummern nicht fest im Code hinterlegen müssen (dies hätte zur Folge, dass bei Änderung einer Nummer oder des Scripts die Application deregistriert und neu registriert werden muss oder die RTCSRV Dienst neu gestartet werden muss) hinterlegen wir diese Nummern in einer simplen Textdatei (bei einem Enterprise Pool empfiehlt sich das Lync Share bei einem STD Pool kann das ein lokaler Pfad sein).
In unserem Script wird dies mit folgenden Elementen gemacht:
<lc:file Name="BlockedTelephoneNumbers"
path = "\\<Lync Share>\BlockCaller\BlockedTelephoneNumbers.txt"
delimitedBy="comma"
keyColumnName="Phone"
static="false">
<lc:column name="Phone" />
<lc:column name="Action" />
</lc:file>
Hiermit Tteilen wir dem Script den Namen, den Pfad und die Spalten der CSV Datei mit. diese sieht bei mir so aus:
Phone,Action
+XXXXXXXXXXXX,block
bei den Nummern daran denken, dass es exakt die Nummer sein muss, welche vom Gateway an den Lync/SfB geliefert wird (bei uns E.164 inkl führendem „+“).
Nun teilen wir unserem Script noch mit, ab unsere Logik nur in dieser Skript Datei steckt, oder ob wir managed Code zusätzlich benutzen:
<lc:scriptOnly/>
Unsere Logik steckt in unserem Script, daher ScriptOnly (ohne managed Code in anderen Dateien).
Zusammen sieht unser Script nun so aus:
<?xmlversion="1.0"?>
<lc:applicationManifest
<lc:requestFiltermethodNames="ALL"strictRoute="false"
    registrarGenerated="true"domainSupported="true"/ >
<lc:responseFilterreasonCodes="ALL"/>
<lc:proxyByDefaultaction="false"/>
<lc:file Name="BlockedTelephoneNumbers"
path = "\\<Lync Share>\BlockCaller\BlockedTelephoneNumbers.txt"
delimitedBy="comma"
keyColumnName="Phone"
static="false">
<lc:column name="Phone" />
<lc:column name="Action" />
</lc:file>
<lc:scriptOnly/>
Zum Abschluss unserer Datei muss nun noch etwas Logik abgebildet werden. Dies tun wir in den folgenden Elementen:
<lc:splScript>
    <![CDATA[ /* Hier kommt unsere Logik */ ]]>
</lc:splScript>
Diese Logik sieht bei uns so aus:
if(sipRequest.Method == „INVITE“){
fromUser = GetUserName(GetUri(sipRequest.From));
toUser = GetUserName(GetUri(sipRequest.To));
sep = IndexOfString(fromUser, „;“);
      Log („Debugr“, false, „CallerIDBlock processing request:“);
Log („Debugr“, false, „From – „, fromUser);
Log („Debugr“, false, „To – „, toUser);
if(sep != -1) {
fromUser = SubString(fromUser, 0, sep);
}
      action = BlockedTelephoneNumbers[fromUser].Action;
if(action == „block“) {
Log („Debugr“, false, „Rejected by CallerIDBlock“);
Respond(403, „Forbidden“);
} else {
Log („Debugr“, false, „Allowed by CallerIDBlock“);
}
}
return;

Nun haben wir also unsere Script Datei: BlockCaller

Der Letzte Schritt ist das Script in unserer Lync/SfB Umbgebung einzubinden. Hier sind zwei Dinge zu beachten:
1) Die Script Datei muss von jedem Frontendserver im Pool erreichbar sein (als empfiehlt sich bei einem Ent. Pool das Lync Share für Script und Resourcen Datei (unsere CSV)
2) unsere Namspace URI im Header
Mittels Lync Management Shell wird nun ein ApplicationServer erzeugt und Ihm die Logik unseres Scriptes mitgegeben:
New-CsServerApplication -Name „BlockCaller“ -Uri „http://blog.rouven-hausner.de/BlockCaller“ -Enabled $true -ScriptName ‚C:\MSPL Scripting\BlockCaller.am‘ -Critical $false -Priority 5 -Parent „service:<Euer FrontPool FQDN>“
Nun werden alle Calls mit den Absendernummern in der CSV Datei mit 403 abgewiese (geblockt)!
Viel Spass und Erfolg!

SfB Skype Verzeichnissuche

Mit Skype for Business Backend gibt es nun die Möglichkeit den Benutzern, die berechtigt sind PIC (Public Instant Messaging Connectivity) zu benutzen, eine Suche im Skype Verzeichnis zur Verfügung zu stellen.

Hierzu gibt es einige Voraussetzungen!

1) die Frontend-Server und Edge Server müssen zwingend Skype for Business sein (das Deployment zeige ich in einem anderen Beitrag)
2) der Provisioning Prozess bei Microsoft muss erfolgreich abgeschlossen sein (https://pic.lync.com)
3) Port 4443 TCP muss vom öffentlichen SIP (Access Edge Interface) zu die MS Servern geöffnet sein, um eine Verbindung mit dem „Graph“ Service zum Durchsuchen des Skype Verzeichnisses aufzubauen

Nun zu unseren Tasks:

Wir müssen den Skype Public Provider in unserer SfB Umgebung aktualisieren. Dies passiert mittels Lync Management Shell:
New-CsPublicProvider -Identity Skype -ProxyFqdn federation.messenger.msn.com -IconUrl https://images.edge.messenger.live.com/Messenger_16x16.png
-NameDecorationRoutingDomain msn.com -NameDecorationExcludedDomainList „msn.com,outlook.com,live.com,hotmail.com“ -VerificationLevel UseSourceVerification -Enabled $true -EnableSkypeIdRouting $true -EnableSkypeDirectorySearch $true

Der letzte Parameter -EnableSkypeDirectorySearch $true aktiviert die Möglichkeit zur Suche im Skype Verzeichnis.

Bei erfolgreicher Konfiguration, sieht es bei einem PIC berechtigten Benutzer im Client so aus:

Auswahl, welcher externe Kontakttyp hinzugefügt werden soll:

AddSkypeContact

 

Skype Verzeichnissuche:

SkypeDirectorySearch

Viel Erfolg

Rouven

Copy and Paste im Lync/SfB Client

Im Mai 2015 veröffentlichte Microsoft ein Clientupdate mit dem Artikel KB3039779.

Dieses Update bringt zwei interessante Features mit sich.
1) Es lässt sich nun in den Lync Optionen einstellen, ob bei einem „Copy and Paste“ von einer IM der Name und Zeitstempel mit in die Zwischenablage kopiert wird.
CaP_SfB

Das bringt aber eine Einschränkung mit sich. Es kann nun leider nicht mehr der komplette Chatverlauf markiert werden im Kontextmenü.
CuP_SfB_Limitation
2) Bei einer Einladung zu einem Lync/SfB Meeting wird darauf hingewiesen, dass es sich um eine Skype for Business (und nicht Skype) Einladung handelt.
SFBInvitation

 

Ich hoffe das hilft etwas weiter.

Viel erfolg

Rouven

Skype UI im Client kontrollieren

Im April 2015 wurde ein optionales Update für den Lync 2013 Client seitens MS bereitgestellt, unter dem KB2889923. Beim ersten Start des aktualisierten Lync/SfB Clients wird der User aufgefordert sein zukünftiges UI zu wählen. Diese Abfrage kommt schon im neuen Stil des UI. Eine nicht geplante/vorhergesehene und nicht koordinierte Aktualisierung der Oberfläche führt in der Regel zu erhöhten Ticketaufkommen und/oder Bedienungsfehlern/Missverständnissen bei Benutzern.

Diese Aktualisierung lässt sich per Clientpolicy steuern via Lync Management Shell steuern.

Eine Übersicht über die vorhanden Clientpolicies erhält man mittels Get-CSClientPolicy, eine neue ClientPolicy wird mittels New-CSClientpolicy angelegt, eine bestehende Clientpolicy wird mittels Set-CSClientPolicy geändert.
die New- und Set- CMD-Lets haben einen Parameter -EnableSkypeUI welcher mit $true (einschalten) oder $false (ausschalten) aufgerufen werden kann.

Hier wir in der Globalen Client Policy die SkypeUI deaktiviert:
Set-CSClientPolicy global -EnableSkypeUI $false

DisableSkypeUI

 

Hier wir in der Globalen Client Policy die SkypeUI aktiviert:
Set-CSClientPolicy global -EnableSkypeUI $true

EnableSkypeUI

 

Bei einer neu angelegt bzw. nicht der globalen Richtline muss man noch berücksichtigen, diese Richtlinie dem User mittel Grant-CSClientPolicy zuzuweisen.

Bei der nächsten Anmeldung sollte der Client nun im Skype Look and Feel oder Lync 2013 Look and Feel starten.

Viel Erfolg

Rouven