Neben dem CU5 HF3 und der Möglichkeit das LastActive-Attribut zu entfernen gibt’s noch etwas neues: den CSContactImporter.

Dieses Tool ermöglicht es nun (endlich!) Kontakte aus fremden Quellen zu importieren. Hierzu wird die aktuelle Kontaktliste mittels DBImpExp exportiert, anschließend kann man die exportierte Datei durch weitere Kontakte ‘anreichern’. Hierzu zeigt man auf die Datei mit den zu importierenden Kontakten, diese können aus folgenden Quellen stammen:

• AOL Instant Messanger (blt export, version 2)
• Windows Live (csv export)
• YAHOO Messenger (csv export)
• Plain Text (user@domain.tld,Gruppe)

Das Tool erstellt dann eine neue xml-Datei welche über DBImpExp wieder importiert werden kann.

Einen Batchmodus gibt es auch, hier wird dann pro User eine eigene Quelldatei mit den hinzuzufügenden URIs erwartet.

Nach der Installation findet sich im Programverzeichnis vom CSContactImporter eine Readme.rtf, hier kann man das alles auch nochmal im Detail nachlesen.

• DL: http://www.microsoft.com/download/en/details.aspx?id=29558

der ein oder andere kennt diese Diskussion vielleicht aus eigner Erfahrung, entweder intern, mit Kollegen aus dem Team, seitens des Betriebsrats oder auch mit Gesprächen mit Kunden und Partnern. “Lync kann man ja zur Leistungsüberwachung einsetzen” heißt es da dann, es ist ja ein leichtes zu erkennen wer wann wie lange nicht gearbeitet hat! Dies bezieht sich dann üblicherweise auf diese Anzeige, das Attribut ‘LastActive’:  

Meine übliche Argumentation in diesen Fällen sieht in etwa so aus: Es ist grundsätzlich richtig dass ich erkennen kann wie lange der Statuswechsel einzelner Personen zurückliegt, dient letztlich dazu die Kommunikation steuern zu können. Ist er nur gerade eben weg? Dann kann ich vielleicht einfach noch einen kleinen Moment warten, er kommt ja vielleicht gleich wieder. Oha, schon drei Stunden weg? Na dann ist er wohl auf seinem Termin den ich auch im Kalender sehe, dann schicke ich ihm liebe einer Mail oder unterhalte mich mit seiner Mailbox.

Das ist im Prinzip nicht großartig anders als die Information welche ich vom Telefon bekommen kann, sei’s über das gute alte ‘Belegtlampenfeld’ oder den Besuch im Büro.

Was Lync eben nicht bietet ist eine automatisierte, dauerhafte und kontinuierliche Aufzeichnung der Präsenzinformationen über eine Zeit hinweg. Und genau das wäre  – meiner Meinung nach – ja das was man für eine Leistungserfassung (oder ähnliches) benötigten würde. Denn so wie es heute ist kann ich mir zwar quasi jederzeit die Informationen zu meinen Kollegen anschauen und manuell ein Protokoll führen, aber das ist schon mit ganz ordentlichem Aufwand verbunden.

Dennoch – hier gibt es ein Thema welches in dem ein oder anderen Projekt durchaus zu Problemen und Diskussionen geführt hat und bisher lediglich über 3rd Partylösungen zufriedenstellend zu lösen war.

Hier hat sich nun etwas getan!

Heute wurde das Hotfix 3 fürs CU5 – oder kurz CU5 HF3 – veröffentlicht. Hier verbirgt sich in der Liste der gefixten Themen dann folgender Artikel:

An update is available for Lync Server 2010 to remove the LastActive attribute from the aggregation state category

http://support.microsoft.com/kb/2684128

Dieses Update ermöglicht es nun dieses Attribut ‘LastActive’ aus der Präsenzinformation zu entfernen. Hierzu wird zunächst die Lyncumgebung über den Serverupdateinstaller.exe auf die Version 4.0.7577.0198 gepatcht. Anschließend kann man in der Datei  Rtcaggregate.exe.config folgenden Schlüssel hinzufügen und anpassen:

<configuration>
    <appSettings>
      <add key="PublishLastActive" value="false" />
    </appSettings>
</configuration>

Diese Änderung muss auf allen Frontendservern erfolgen, hier wird das Präsenzdokument verarbeitet und der Präsenzstatus errechnet. Nach einem Neustart gibt’s dann keine Informationen mehr wie lange die letzte Änderung her ist!

Hier noch die Links zum CU5 HF3

• KB: http://support.microsoft.com/kb/2698370
• DL: aktuell kein direkter DL-Link verfügbar, muss individuell angefragt werden.

http://www.microsoft.com/downloads/details.aspx?FamilyID=9C05FC86-D625-4132-ABC7-2841C39226B9&displaylang=e&displaylang=en

Hier ist ein DC, eine Lync Standard Edition, ein QoE Monitoring & Archiving, Exchange UM und Sharepoint enthalten und alles installiert das man unmittelbar loslegen kann. Sei’s dass man die Umgebung nimmt wie sie ist oder hier und da noch etwas dran ändert, hinzuinstalliert und anpasst.

Diese Laborumgebung wird als VHD ausgeliefert, lässt sich also ganz wunderbar in Hyper-V laden (der Win 8 Client hat nun auch Hyper-V!), oder auch mit beliebigen 3rd Party VM-Tools betreiben (vmware Player, Oracle VirtualBox oder auch beliebige andere).

Was die Lync-Seite betrifft ist das ja alles ganz wunderbar hübsch. Allerdings kommt man dann irgendwann vermutlich auch mal zu dem Punkt wo’s dann nur mit Lync nicht mehr getan ist und man auch eine Anbindung in Richtung TK-Anlage herstellen oder zumindest simulieren möchte. Hier hatte ich bisher für mich noch keine wirklich heiße Idee.

Bis ich dann kürzlich über folgenden Link gestoßen bin:

http://windowspbx.blogspot.de/2011/09/using-snom-one-as-sip-trunk-gateway-for.html

Hier wird beschrieben wie man sich mit der kleinsten, kostenlosen Variante von Snom One eine SIP-Anbindung für Lync bauen kann. Dazu noch ein X-Lite Client als SIP-Endpunkt für Snom und die Sache ist rund

http://www.counterpath.com/xlite-comparison.html

Viel Spaß!

Nunja, diejenigen unter uns welche RCC einsetzen kennen das leidige Spiel ja vermutlich. Sobald ein Benutzer für RCC konfiguriert wurde, sind im Client sämtliche Konfigurationen für Video verschwunden. Weder konnte man einen Videocall durchführen, die Kamera einrichten noch ähnliches. Immerhin ist dies auch genau so lapidar in den Release Notes zu Lync beschrieben:

Release Limitations of Remote Call Control (RCC) Support

Issue:

For users who are using Remote Call Control (RCC), Lync 2010 will not support the following features:

• Downloading of normalization rules

• Video calling for RCC users

• Transferring conferences to user’s own numbers

• Join From dialog box when joining conferences

Resolution:

There currently is no workaround for this issue.

Microsoft Lync 2010 (RTM) Release Notes

Wobei der letzte Satz so nicht mehr ganz richtig ist. Denn genau hieran hat sich im CU5 etwas getan! Gut versteckt in den Hinweisen zum CU5 gibt es einen Verweis auf den KB-Artikel welcher ankündigt dass nun doch Video möglich ist! Und das ist schon wirklich gut so Zwar kann für ein PBX-Telefonat kein Video hinzugefügt werden (Split-A/V), aber das ist ja auch durchaus nachvollziehbar und macht in den aller meisten Fällen ja auch Sinn. Aber für Lync-zu-Lync Gesprächen und vorallem für Konferenzen kann nun eben Video verwendet werden! Alles was es hierzu braucht ist das CU5, hier mal eine Sammlung der relevanten Links.

Einmal für den Client:

KB (Video & RCC): http://support.microsoft.com/kb/2666709

KB: http://support.microsoft.com/kb/2670326

DL x86: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=25055

DL x64: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14490

Und den Server:

KB: http://support.microsoft.com/kb/2493736/en-us

DL: http://www.microsoft.com/download/en/details.aspx?id=11551

Auch für die Telefone (aka Lync Phone Edition) gibt es Updates, für die Geräte aus der Aries-Serie:

AAstra 6721ip & 6725ip: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18390

HP 4110 & 4120: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28158

Polycom CX500, CX600 & CX3000: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=23866

Und die guten alten Tanjays:

Polycom CX700 & LG Nortel 8540:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21644

Für die Installation auf den Servern gilt das gleiche wie für alle weitren Lync-Updates, bitte immer immer die aktuellen Serverupdateinstaller.exe herunterladen. Diese aktualisiert sich nicht automatisch gegen das Internet! Frisch herunterladen und dann alle Server der Reihe nach damit aktualisieren. Und das Datenbankupgrade nicht vergessen. Das habe ich im Blog-Eintrag zum CU3 beschrieben, vielleicht ists keine schlechte Idee wenn ich hierzu nochmal einen separaten Eintrag schreibe. So ein ‘wie installiere ich die Updates auf Lync, woran muss ich denken und was gibts zu beachten?’…

Wenn man nun in der Situation eines Log-Storm ist, die Transaktionsprotokolle der Exchangedatenbanken also ordentlich anwachsen, ist so ein wenig die Frage was man tut. Zum einen kann man in der Situation ExMon auf dem Mailboxserver einsetzen, ein gutes Werkzeug um zu erkennen welcher Benutzer aktuell die Last erzeugt. Aber das muss manuell geschehen. Klappt dann zwar zuverlässig, aber eben nur manuell und wenn man merkt das man eh schon ein Problem hat. Ja, nett, aber..

Was tun um das irgendwie automatisch, quasi proaktiv wie’s so schön heißt, erkennen zu können? Klar, Microsoft Systemcenter Operations Manager mal grad eben installieren und damit die Umgebung überwachen. Ja gut, mit grad mal eben ists nicht getan, ich geb’s ja zu.

Allerdings, und hier wirds dann schon wieder spannend, gibts im Scripts-Ordner der Exchangeinstallation (%programfiles%\Microsoft\Exchange Server\V14\Scripts) ein Scripts names “Troubleshoot-DatabaseSpace.ps1”.

Diese Script überwacht zum einen das Wachstum des Speicherplatzbedarfs, identifiziert bei Bedarf die User welche für das Wachstum verantwortlich sind und kann diese sogar isolieren. Darauf wie das im Detail funktioniert und an welchen Schrauben man drehen kann möchte ich hier nicht eingehen sondern gerne auf einen Technet-Artikel verweisen, hier gibts eigentlich mal ganz gute Informationen zu dem Sachverhalt:

• http://technet.microsoft.com/de-de/library/ff477617.aspx

Allerdings, und nun kommts eben mal wieder, gibts auf einem deutschen System leider ein paar Probleme mit nämlichen Script. Diese sehen in etwa so aus:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>.\Troubleshoot-DatabaseSpace.ps1 -Server iqmail02

Get-Counter : Das angegebene Objekt wurde nicht auf dem Computer gefunden.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\Troubleshoot-DatabaseSpace.ps1:155 Zeichen:39

+ $logBytesCounter = get-counter <<<< -ComputerName $database.MountedOnServer -Counter $counterName -MaxSample

s 10

+ CategoryInfo : InvalidResult: (:) [Get-Counter], Exception

+ FullyQualifiedErrorId : CounterApiError,Microsoft.PowerShell.Commands.GetCounterCommand

Die CounterSamples-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:315 Zeichen:28

+ $total += ($sample. <<<< CounterSamples | ?{$_.Path -like "*$counterName*"}).CookedValue

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

Die length-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:317 Zeichen:29

+ return $total/($results. <<<< length)

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

Get-Counter : Das angegebene Objekt wurde nicht auf dem Computer gefunden.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\Troubleshoot-DatabaseSpace.ps1:155 Zeichen:39

+ $logBytesCounter = get-counter <<<< -ComputerName $database.MountedOnServer -Counter $counterName -MaxSample

s 10

+ CategoryInfo : InvalidResult: (:) [Get-Counter], Exception

+ FullyQualifiedErrorId : CounterApiError,Microsoft.PowerShell.Commands.GetCounterCommand

Die CounterSamples-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:315 Zeichen:28

+ $total += ($sample. <<<< CounterSamples | ?{$_.Path -like "*$counterName*"}).CookedValue

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

Die length-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:317 Zeichen:29

+ return $total/($results. <<<< length)

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

Get-Counter : Das angegebene Objekt wurde nicht auf dem Computer gefunden.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\Troubleshoot-DatabaseSpace.ps1:155 Zeichen:39

+ $logBytesCounter = get-counter <<<< -ComputerName $database.MountedOnServer -Counter $counterName -MaxSample

s 10

+ CategoryInfo : InvalidResult: (:) [Get-Counter], Exception

+ FullyQualifiedErrorId : CounterApiError,Microsoft.PowerShell.Commands.GetCounterCommand

Die CounterSamples-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:315 Zeichen:28

+ $total += ($sample. <<<< CounterSamples | ?{$_.Path -like "*$counterName*"}).CookedValue

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

Die length-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:317 Zeichen:29

+ return $total/($results. <<<< length)

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

Get-Counter : Das angegebene Objekt wurde nicht auf dem Computer gefunden.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\Troubleshoot-DatabaseSpace.ps1:155 Zeichen:39

+ $logBytesCounter = get-counter <<<< -ComputerName $database.MountedOnServer -Counter $counterName -MaxSample

s 10

+ CategoryInfo : InvalidResult: (:) [Get-Counter], Exception

+ FullyQualifiedErrorId : CounterApiError,Microsoft.PowerShell.Commands.GetCounterCommand

Die CounterSamples-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:315 Zeichen:28

+ $total += ($sample. <<<< CounterSamples | ?{$_.Path -like "*$counterName*"}).CookedValue

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

Die length-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:317 Zeichen:29

+ return $total/($results. <<<< length)

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

Get-Counter : Das angegebene Objekt wurde nicht auf dem Computer gefunden.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\Troubleshoot-DatabaseSpace.ps1:155 Zeichen:39

+ $logBytesCounter = get-counter <<<< -ComputerName $database.MountedOnServer -Counter $counterName -MaxSample

s 10

+ CategoryInfo : InvalidResult: (:) [Get-Counter], Exception

+ FullyQualifiedErrorId : CounterApiError,Microsoft.PowerShell.Commands.GetCounterCommand

Die CounterSamples-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:315 Zeichen:28

+ $total += ($sample. <<<< CounterSamples | ?{$_.Path -like "*$counterName*"}).CookedValue

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

Die length-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:317 Zeichen:29

+ return $total/($results. <<<< length)

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

Get-Counter : Das angegebene Objekt wurde nicht auf dem Computer gefunden.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\Troubleshoot-DatabaseSpace.ps1:155 Zeichen:39

+ $logBytesCounter = get-counter <<<< -ComputerName $database.MountedOnServer -Counter $counterName -MaxSample

s 10

+ CategoryInfo : InvalidResult: (:) [Get-Counter], Exception

+ FullyQualifiedErrorId : CounterApiError,Microsoft.PowerShell.Commands.GetCounterCommand

Die CounterSamples-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:315 Zeichen:28

+ $total += ($sample. <<<< CounterSamples | ?{$_.Path -like "*$counterName*"}).CookedValue

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

Die length-Eigenschaft wurde für dieses Objekt nicht gefunden. Stellen Sie sicher, dass sie vorhanden ist.

Bei C:\Program Files\Microsoft\Exchange Server\V14\Scripts\StoreTSLibrary.ps1:317 Zeichen:29

+ return $total/($results. <<<< length)

+ CategoryInfo : InvalidOperation: (.:OperatorToken) [], RuntimeException

+ FullyQualifiedErrorId : PropertyNotFoundStrict

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>

Und das Script tut auch nicht, im Ereignisprotokoll müssten eigentlich die Ergebnisse landen, dort steht aber stets es gäbe ein Wachstum von 0 Byte – was für viele Umgebungen eben nicht unmittelbar zutrifft.

Irgendwann, es hat schon ne Weile gedauert geb ich zu, hat’s mich dann genervt und ich hab mir die Scriptausführung mal Schritt für Schritt angeschaut um den Fehler zu finden. Denn die Meldung “Das angegebene Objekt wird nicht gefunden” hört sich ja mal so an als wie wenn ob es da ein Problem mit einem Namen geben würde… Und genau so wars dann auch! In Zeile 154 wird auf ein Performancecounter verwiesen:

$counterName = "\MSExchangeIS Mailbox($database)\JET Log Bytes Generated/hour"

Nur leider leider heißen die Performancecounter im Deutschen anders.

Wenn man sich nun eine Kopie des Scripts anlegt, diese folgendermaßen editiert:

$counterName = "\MSExchangeIS Postfach($database)\JET-Protokoll: Generierte Bytes/Stunde"

Läuft das Script, und zwar mit ohne Fehler!

Das Ergebnis lässt sich dann im Ereignisprotokoll “Microsoft-Exchange-Troubleshooters/Operational” finden, hier gibts zu jeder Datenbank zwei Einträge, einmal die Event-ID 5000 (Bearbeitung der Datenbank XXX begonnen) und die Event-ID 5001 (Ergebnis):

Die Problembehandlung für den Datenbankspeicherplatz auf Volume ‘E:\’ für Datenbank ‘IQ XXXX’ wurde abgeschlossen. Es wurden keine Probleme erkannt.
Freier Speicherplatz auf dem EDB-Laufwerk: 34047885312 B
Freier Speicherplatz auf dem Protokolllaufwerk: 19168886784 B
Schwellenwert für freien Speicherplatz auf dem EDB-Laufwerk: 0%
Schwellenwert für freien Speicherplatz auf dem Protokolllaufwerk: 0%
Stundenschwellenwert: 0 h
Aktuelle Wachstumsrate: 745498 B/h

In meiner Lync-Umgebung gab es kürzlich ein Problem mit einigen abgehenden PSTN-Gesprächen. Und zwar immer mit der selben Zielrufnummer, aber nur von Lync aus. Die selbe Rufnummer konnte über den selben ISDN-Anschluss von einem ‘normalen’ Telefonanlagentelefon (jaja sowas hab’ ich schon auch noch..) wunderbar erreichen. Am Anschluss liegts also nicht, und bis vor nicht all zu langer Zeit lief das schon auch noch. In meinem Fall ging es hierbei bezeichnender Weise um eine Hotline von Microsoft mit einer deutschen Rufnummer, ähnliches Verhalten wurde aber auch schon von internationalen Gesprächen gemeldet, und zwar immer dann wenn ein Mobilfunkteilnehmer angerufen wurde. Normale Gespräche ins Ausland gehen, aber Handy geht nicht.

Wie stellt sich das ganze dar? So:

Der Anruf kann nicht durchgeführt werden. Versuchen Sie es später erneut.

Der Anruf konnte aufgrund eines ausgelasteten Netzwerks nicht durchgeführt werden. Versuchen Sie es später erneut.

Also mal nach der Ursache suchen, immerhin lässt sich der Fehler reproduzieren, was die Suche deutlich vereinfacht. Der erste Hinweis findet sich dann gleich im Ereignisprotokoll des Mediationservers:

Could not route to Gateway IQSIPGate01.fqdn, the attempt failed with response code: Timeout (CallID: d4d638cfcd9143879192be4f413845c9).

Failure occurrences: 7, since 19.12.2011 07:14:07.

Cause: A gateway failed to respond to a request within allotted time or was unable to route the request due to some error.

Resolution:

Check whether the specified gateway is up and is properly configured.

Wobei ich mir sicher sein kann dass das Gateway läuft und korrekt funktioniert, immerhin telefonieren wir alle darüber. Also weiter in die Logs schauen, zunächst mal in die Protokolle des Clients, hier findet sich in Snooper dann folgendes:

01/02/2012|13:10:42.173 8CC:4B8 INFO  :: Data Received – 192.168.30.14:5061 (To Local Address: 192.168.30.139:49759) 778 bytes:

01/02/2012|13:10:42.173 8CC:4B8 INFO  :: SIP/2.0 503 Service Unavailable

Authentication-Info: TLS-DSK qop=”auth”, opaque=”18D5EAF8″, srand=”34677BF8″, snum=”718″, rspauth=”75dbe97b8541a7f3dace1abd4a4d7ac11fd0ef82″, targetname=”IQAPP22.fqdn”, realm=”SIP Communications Service”, version=4

Content-Length: 0

Via: SIP/2.0/TLS 192.168.30.139:49759;ms-received-port=49759;ms-received-cid=929200

From: “Martin Rinas”<sip:mrinas@iq-gmbh.de>;tag=7fe286291b;epid=7ded67a383

To: <sip:+498004007400@iq-gmbh.de;user=phone>;tag=D260A0C37F0E8E21D19A37B07168E04C

Call-ID: 6b3529ce9f4f40ca9b9b4e25489a96b7

CSeq: 1 INVITE

ms-diagnostics: 12000;reason=”Routes available for this request but no available gateway at this point“;source=”IQAPP22.fqdn”;appName=”OutboundRouting”

Server: OutboundRouting/4.0.0.0

Mmh, also irgendwas scheint mit dem Gateway nicht zu passen, laut ms-diagnostics Header.

Also wieder zurück auf den Mediationserver und dort das Logging für S4 aktivieren und die Traces anschauen. Hier sieht man dann dass das Gespräch durch den INVITE in Richtung Gateway gestartet wird, dies auch korrekt durch ein 200 OK beantwortet wird und nach 8-10 Sekunden Lync dann ein CANCEL hinterher schickt:

Wenn man sich dann noch die Mühe macht die Syslogs vom Gateway auszuwerten und die Q.931 Meldungen aus dem ISDN decodiert – was bei unsrem Ferrari Gateways sehr schön geht – kann man hier erkennen dass der Rufaufbau gestartet wird, aber eben noch nicht abgeschlossen ist. Das Gespräch ist noch nicht bis zum Ziel durchgestellt, es klingelt noch nicht.

Letztlich ist dieses Verhalten dann auf das CU4 für Lync zurückzuführen, hier wurde eine Anforderung an (enhanced) Media Gateways konsequenter als bisher umgesetzt. So muss ein Gateway noch vor dem eigentlichen ISDN-Rufaufbau einen ‘Session Progress’ melden. Wird dieser Session Progress nicht vom Gateway gesendet, bricht Lync nach 8-10 Sekunden das Gespräch wieder ab.

Hierzu gibts auch einen hübschen Beitrag von Johan Deutinger:

• http://social.technet.microsoft.com/Forums/sr-Latn-CS/ocsvoice/thread/892989e2-2978-4bef-be9a-b2c655c97188

Hierzu wird im Gateway ‘Early Progress’ aktiviert, bei meinem Ferrari Gateway geht das in den VOIP-Parametern:

Und schon klappts mit dem Nachbarn.

Das lag jetzt nicht an so was wie Urlaub oder so, ganz im Gegenteil. Seit Ende November treibe ich mich bei Microsoft rum und bemühe mich redlich um den Status eines MCM für Lync 2010 zu erlangen.

nur mal ein kurzes Update hierzu, quasi in eigner Sache. Es ist geschafft! Ich darf mich seit dem 19. Dezember voller Stolz Microsoft Certified Master Lync 2010 nennen! Zwei von dreizehn Teilnehmern haben es im ersten Anlauf geschafft, an dieser Stelle möchte ich Jamie Schwinn – mit dem ich sehr viele Stunden am Whiteboard, in unsrer Laborumgebung und in Diskussionen verbracht habe – zum Bestehen gratulieren! Wir dürfen uns nun zum erlauchten Kreis der gut 30 Lync Master zählen, recht viel mehr hat’s da im der Tat noch nicht..

… More to come …

Nun hatten wir seit gestern schon in zwei Installationen Probleme mit genau dieser automatischen Installation über Windows Update. WAS? Automatische Updates auf einem Server? Ist der noch zu retten? Ich hör’s bis hier

Ja doch, ist er schon, glaub’ ich zumindest. Denn aufgetreten ist das Problem auf den Edgeservern, diese stehen auf automatisch herunterladen und installieren, weil dort die Unternehmensinternen Patchmanagementmechanismen häufig eben nicht ziehen. Und da macht das dann grundsätzlich durchaus Sinn. Oder kann zumindest Sinn machen.

However.

Jedenfalls ist es so dass nach der automatischen Installation des RU6 auf dem Edgeserver der Dienst Microsoft Exchange-Transport (MSExchangeTransport) nicht mehr gestartet wird. Was dann zur Folge hat dass die gesamte externe Emailkommunikation (ankommend und abgehend) nicht mehr läuft und auf den internen HubTransport-Servern die Warteschlange voller und voller wird.

Der Dienst lässt sich dann relativ bequem und problemlos wieder starten und danach geht dann auch wieder alles.

Aber es muss eben manuell passieren. Und man sollte auch zusehen dass alle weiteren Exchangeserver dann auch in absehbarer Zeit wieder auf einem homogenen Patchlevel laufen, das ist mal generell keine schlechte Idee…

Aber wie kann das sein, immerhin bin ich doch Domänen-Admin, und wer wenn nicht ich sollte hier administrieren können?!

Wenn man die Fehlermeldung erweitert, gibt’s ein paar weitere Hinweise:

Active Directory operation failed on “<myDC>”. You cannot retry this operation: “ Die Zugriffsrechte reichen für diesen Vorgang nicht aus 00002098: SecErr: DSID-03150BB9, problem 4003 (INUSS_ACCESS_RIGHTS), data 0”. You do not hae the appropriate permissinos to perform this operation in Active Directory. One possible casue is that the Lync Server Control Panel and Remote Windows PowerShell cannot modify users who belont to protected security groups (for example, the Domain Admins group). To manage users in the Domain Admins group, use the Lync Server Managemnt Shell and log on using a Domain Admins account. There are other possible causes. For details, see Lync Server 2010 Help.

Wenn man da dann genau hinschaut und sich die Fehlermeldung wirklich mal komplett durchliest, ja ich weiß wer macht das schon…, hat man schon mal einen ganz wichtigen Hinweis auf die Fehlerursache. Ist der zu editierende Benutzeraccount Mitglied in einer ‘besonders geschützten Gruppe’ klappt’s nicht.

Aber was hat es damit auf sich, woher kommt das und warum? Und warum hat man das nicht schon mal an andrer Stelle bemerkt, braucht’s dafür wirklich erst Lync darüber zu stolpern?

Nun die letzte Frage ist mal recht einfach zu beantworten, auch im Bereich Exchange stolpert man durchaus über dieses Verhalten: Beispielsweise immer dann wenn (beispielsweise) ein Domänen-Admin ActiveSync nutzen will. Dann klappt das genau für diesen Account eben nicht, wohingegen alle andren problemlos synchronisieren können. Oder auch die Blackberry-Anbindung, hier ist’s das gleiche. Geht für alle, nur eben für die Admins nicht. Beim Versuch diesen Account zu synchronisieren gibt’s in er Ereignisanzeige des Exchange dann auch einen Eintrag welcher auf fehlende Rechte hinweist. Grad aktuell habe ich leider kein geeignetes System zur Hand um einen Screenshot produzieren zu können, der schieb’ ich dann aber nochmal nach.

Gut, zurück zum Problem, es geht also um besonders geschützte bzw. schützenswerte Gruppen und hat irgendwas mit Berechtigungen zu tun.

Während der Installationsphase von Lync und Exchange (genauer gesagt im Bereich der AD-Vorbereitung) werden durch den Setup-Assistenten die Berechtigungen im AD angepasst. Hier werden auf oberster Ebene ein paar neue ACL-Einträge gesetzt damit die Exchange Server, die Lync Server und auch die zugehörigen Admin-Gruppen Rechte auf die spezifischen Eigenschaften der Accounts haben. Diese werden eben ganz oben gesetzt und dann vererbt. Also alles fein:

Hier nur ein Beispiel einiger Einträge, mir geht es hier konkret um die Berechtigungen für die Gruppen RTC…

Also, Berechtigungen sind oben gesetzt und werden dann auch nach unten vererbt. So what?

Nun, hier zieht ein spezieller Schutzmechanismus des Active Directory. Da man ja im AD über Berechtigungen so ziemlich alles erlauben und verbieten kann, und sich diese Berechtigungen dann auch auf alle untergeordneten Objekte durchvererben, könnte man sich ja folgendes Szenario überlegen:

Dem Helpdesk wurde der Task ‘Kennwörter für Benutzer zurücksetzen’ delegiert und auch das entsprechende Recht auf Benutzerobjekte gewährt. Leider liegen in der entsprechenden OU nun nicht nur die Benutzeraccounts sondern, aus welchem Grund auch immer, auch administrative Accounts. Dann wäre der Helpdesk also in der Lage das Kennwort eines Domänen-Admins zurückzusetzen und sich damit entsprechende Berechtigungen so organisieren.

Das ist nicht schick und soll verhindert werden!

Aus diesem Grund überprüft das Active Directory regelmäßig alle Mitglieder von speziell geschützten Gruppen und entfernt dort den Haken ‘Vererbte Berechtigungen übernehmen’ und ersetzt diese Berechtigungen durch jene welche auf das AdminSDHolder-Container im System-Container gesetzt sind:

Benutzer ist Mitglied in den Domänen Admins? Vererbung abschalten, Berechtigungen ersetzen.

Das erklärt dann beispielsweise auch warum das Recht ‘SendAs’ vielleicht immer wieder verschwindet, obwohl es doch ganz sicher gesetzt wurde – das wäre dann die Ecke mit den Blackberry-Problemen.

Welche Gruppen sind hiervon betroffen? Seit Windows 2000 SP4 sind es folgende Gruppen:

• Administratoren
• Konten-Operatoren
• Serveroperatoren
• Druck-Operatoren
• Sicherungs-Operatoren
• Domänen-Admins
• Schema-Admins
• Organisations-Admins
• Zertifikatherausgeber

Darüber hinaus die folgenden Benutzer ebenfalls berücksichtigt sind geschützt:

• Administrator
• KRBTGT

Was in pre-Windows2000-SP4 anders war spare ich mir, ich bin mir sicher dass weder Lync noch Exchange 2010 in einer solchen Umgebung läuft – man braucht ja mindestens 2003 native

Soweit so klar, aber was kann man jetzt tun?

Nun, der aus meiner Sicht einzig sinnvolle Weg ist tatsächlich – so überraschend es klingen mag – die strikte Trennung zwischen ‘operativen’ und administrativen Accounts. Ja, natürlich, ein Administrator braucht vermutlich für die meisten Aufgaben administrative Rechte und von dem her auch einen passenden Account. Aber dennoch sollten diese eben nicht auf dem normalen Benutzeraccount liegen sondern auf einem separaten, administrativen, personalisierten Account.

Und alternativ, was kann man da machen? Nun im Fall von Lync und der Aktivierung oder Administration eines Accounts kann man (quasi vergleichsweise bequem) auf die Powershell ausweichen, hier hat man das Problem nicht da hier dann mit den notwendigen Berechtigungen gearbeitet wird.

Im Fall von Exchange ist’s da leider etwas anders, denn es geht hierbei ja nicht drum einmalig etwas einzustellen sondern viel mehr darum dass Exchange für den Betrieb von ActiveSync spezielle Rechte benötigt. Und genau diese fehlen.

Denkbar ist hier die Anpassung der Berechtigungen auf das AdminSDHolder-Objekt im Systemcontainer. Ich möchte hier aber bewusst nicht weiter drauf eingehen, wenn das jemand machen möchte sollte er sich zumindest ein wenig damit auseinandersetzen um zu verstehen was es damit auf sich hat und welche Rechte gesetzt werden müssen..  

Und was ist wenn ein Benutzer definitiv nicht Mitglied einer dieser Gruppen ist und es dennoch nicht geht? Oder der Benutzer eben nicht mehr Mitglied einer dieser Gruppen ist und es dennoch nicht klappt?

Hierfür gibt es einen Fix. Denn die Mitgliedschaft in einer Admin-Gruppe wird letztlich über ein spezielles Attribut ‘adminCount’ geprüft:

Ist nun ein Benutzer nicht mehr Mitglied einer solchen Gruppe wird dieses Flag nicht unbedingt wieder auf 0 gesetzt. Wenn’s nur ein einzelner Benutzer ist kann man das natürlich gerne zu Fuß erledigen, wenn’s dann doch mehr sind hat’s dafür auch ein Script:

http://support.microsoft.com/kb/817433 (hier unter Methode 1)

Das Update heißt offiziell Exchange2010-KB2608646, hier wären dann die passenden Links dazu:

KB: http://support.microsoft.com/kb/2608646

DL: http://www.microsoft.com/download/en/details.aspx?id=27849

Was ist neu, was wurde gefixt, was hat sich getan? Nun, es sind eine Reihe von Problemen seit dem letzten Update gefixt. Hier mal eine Auswahl derer, wobei die Auswahl nicht meine eigne Selektion ist sondern stammt vielmehr direkt vom Exchange Team:

• 2627769  Some time zones in OWA are not synchronized with Windows in an Exchange Server 2010 environment
• 2528854  The Microsoft Exchange Mailbox Replication service crashes on a computer that has Exchange Server 2010 SP1 installed
• 2544246You receive a NRN of a meeting request 120 days later after the recipient accepted the request in an Exchange Server 2010 SP1 environment
• 2616127  “0×80041606″ error code when you use Outlook in online mode to search for a keyword against a mailbox in an Exchange Server 2010 environment.
• 2549183  “There are no objects to select” message when you try to use the EMC to specify a server to connect to in an Exchange Server 2010 SP1 environment

Die gesamte Liste gibt’s im KB-Artikel selber, vielleicht ist hier ja genau das Ding dabei auf welches man schon ewig gewartet hat?

Also mal wieder ein Update für Exchange, nun gut. Könnte man sich denken. Ja schon, aber! Eigentlich ist ja immer alles für etwas gut, oder? So auch hier, nur für den Fall das das Update selber nicht schon Zweck genug ist. Ich habe ja in einem vorherigen Eintrag beschrieben wie man bei der Installation von Updates auf einem Exchange vorgehen sollte. Und genau hierzu gibt es nun ein Update, sogar eins welches einen, zumindest einen kleinen, Trommelwirbel verdient. Finde ich. Und zwar ist’s ja so dass man beim Einsatz von Forefront auf dem Exchange (also der Forefront Protection for Exchange, kurz FPE) vor dem Start des Exchange-Updates die Kopplung zwischen FPE und Exchange über fcsutil aufheben sollte. Und genau hier hat sich nun endlich (!) etwas getan.

In den Kommentaren zum Update kam eben die Frage auf ob man da nicht endlich mal was dran machen könnte, daraufhin gab’s dann folgende Antwort:

@Anonymous: Thanks for the naming catch; fixed that in the post. Also – with current versions of Forefront, running fcsutil is not required; we have confirmed this with Forefront team. While this was needed for older versions, it is not needed anymore.

Das finde ich dann schon wirklich gut so, weil dieses manuelle Entkoppeln war schon ein wenig nervig. Zumal es halt doch hier und da vergessen wurde, dann auf den ersten Blick nix gemacht hat weil immer noch alles ging, aber halt die Unsicherheit blieb was das jetzt an Konsequenzen mit sich bringt – denn für irgendwas war dieser Hinweise ja wohl gut.

Nunja, ein so ein Ding gibts dann dennoch, auch das sei hier erwähnt. Es ist ja häufig nicht zu schaffen alle Systeme gleichzeitig zu aktualisieren, je größer die Umgebung wird, desto eher fährt man auch mal einen Mix an RU-Leveln in der Umgebung. Ich bemühe mich eigentlich schon immer das zu vermeiden, aber es geht halt doch nicht immer.

Hat man nun eine solche Konstellation (ein Teil bereits auf RU6, ein anderer Teil eben noch nicht) wird es im Bereich der Role Based Access Control (RBAC) zu einem bekannten Problem kommen. So führt die Veränderung der RBAC-Rollen im ECP bzw. die Verwendung der cmdlets Get-ManagementRole oder Get-ManagementRoleAssignment zu diesem Fehler:

WARNING: The object MyMailboxDelegation has been corrupted, and it’s in an inconsistent state. The following validation errors happened:

WARNING: The property value you specified, “15″, isn’t defined in the Enum type “ScopeType”.

Das ist darin begründet dass mit dem RU6 die Definitionen für die RBAC angepasst werden. Wenn man in diesen Fehler läuft kann man zwei Dinge tun:

• Die Installation des RU6 auf allen Systemen abschließen
• sich mit der Verwaltungskonsole auf einem Server verbinden welcher bereits auf RU6 gepatcht ist.

Wie verbindet man sich gezielt auf einen speziellen Server für die Administration? In der EMC geht das recht einfach über die Eigenschaften der Exchangeorganisation:

Hier kann man dann einen Server angeben:

In einer Powershell geht das auch, hier verweise ich dann gerne auf den passenden Artikel im TechNet, hier wird auch ganz grundsätzlich geschrieben wie man sich über eine lokale Powershell remote auf einen Exchange verbinden kann – letztlich geht’s ja genau darum:

http://technet.microsoft.com/en-us/library/dd297932.aspx

So, das wars dann aber.

Fast! Einen hab ich noch!.. Es ist ja mal wieder so weit. Nein, Weihnachten steht noch nicht (ganz) vor der Tür, auch wenn ich – ich gestehe es! – die ersten Lebkuchen gekauft und gegessen habe. Nein, vorher gibts ja noch was andres, was mindestens genau so überraschend kommt. Die Umstellung von Sommer- auf Winterzeit. Im Prinzip nicht weiter tragisch, allerdings sollte man berücksichtigen dass in Russland dieser Wechsel nicht mehr vollzogen wird, dort bleibt man auf der Sommerzeit. Auch im Winter. Ich find das ja eine wirklich gute Idee. Aber darum gehts jetzt nicht. Falls das für den ein oder andren relevant ist, bitte darauf achten dass auf den Systemen das Update ‘August 2011 Cumulative Time Zone Update for Windows’ installiert ist. Hier werden die notwendigen Anpassungen gemacht damit.

So, das war’s dann aber.

http://blogs.technet.com/b/exchange/archive/2011/10/28/released-update-rollup-6-for-exchange-server-2010-sp1.aspx