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

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

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

Soweit so gut, also gleich mal installieren, hat sich eh’ grad angeboten.

Aber was ist das? Installation kaum gestartet und schon wieder vorbei!?

Gut, kommt mal vor, Update in der falschen Sprache heruntergeladen oder so. Also doppelt prüfen, nochmal runterladen, gleicher Fehler. Also doch das richtige heruntergeladen, aber was will der Fehler mir sagen, ich hätte kein TMG installiert um das SP2 anwenden zu können? Doch, das ist sogar ganz sicher drauf!

Also mal ein Blick in die Release-Notes und das Technet werfen, hätte man ja eh’ mal machen können.

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

Hier steht dann zum Thema ‘wie installiert man Updates’ ein Link zu diesem Technet-Artikel:

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

Dieser Artikel ist, mal unabhängig vom hier beschriebenen Thema rund ums SP2, sehr gut und beschreibt recht schön was man in einem Array aus mehreren Servern in welcher Reihenfolge wie aktualisieren muss.

In diesem Artikel findet man dann die Aussage dass die Updates fürs TMG kumulativ sind. Also alle vorangegangen Updates enthalten. Klar so ist’s gerade bei den Service Packs ja eigentlich immer. Und das die Basis für die Installation die vorangegangene Version darstellt. Moment mal! Kumulativ heißt doch eigentlich das alle vorangegangenen Updates enthalten sind, sonst wärs ja quasi ein inkrementelles Update!

About service packs and updates

Forefront TMG updates and service packs are cumulative. A service pack for a specific version of Forefront TMG contains all previously released updates and fixes for that version. A service pack or cumulative update can be installed on computers that are running the latest release of Forefront TMG. To install Forefront TMG SP2, you must install the release to manufacturing (RTM) version, followed by SP1, followed by Update1, followed by SP2.

Aber genau so sieht es aus, es ist nach meinem Verständnis weniger ein cumulative update denn mehr ein inkremental Update.

Um das SP2 erfolgreich installieren zu können muss man das TMG zunächst auf SP1 aktualisieren, dann das Update 1 für SP1 installieren und dann das SP2.

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

DL Update 1: http://www.microsoft.com/download/en/details.aspx?id=11445

Wenn man sich an dieses Spiel hält, läufts dann aber ganz gut, mit dem Update aufs SP2.

Der IE9 ist ja ne schicke Sache, so grundsätzlich und überhaupt. Und weil wir ja alle natürlich pflichtbewusst sind, ist der quasi schon überall installiert, natürlich auch auf den Exchange Servern und auf den Admin-PCs, Notebooks und Workstations sowieso. Eh klar. Nun kommt’s aber seit der Installation des IE9 dazu dass sich die Exchange Management Console, die EMC, nicht mehr Schließen lässt. Beim Versucht gibt’s dann nur eine unschöne Fehlermeldung:

Schließen Sie alle Eigenschafenseiten, bevor Sie Exchange-Verwaltungskonsole schließen.

Ja schade nur, denn es sind definitiv keine Eigenschaften mehr offen! Das einzige was dann hilft ist der Griff zum Taskmanager und das beenden des mmc-Prozesses. Unschön, aber tut’s erstmal.

So, dass es also am IE9 lag ist schon eine Weile bekannt, nun gibt es seit heute auch einen Fix hierfür.

Wie kommt man an den Fix, was ist zu machen? Nun, wie’s so häufig ist im Leben müssen zunächst ein paar Voraussetzungen erfüllt werden:

• Es muss eine ‘released’ Version vom IE9 installiert sein, aber eine Beta wirds auf einem Exchange ja wohl kaum geben, oder?!
• das Update MS11-081 muss installiert sein, dieses gibt es hier: http://technet.microsoft.com/en-us/security/bulletin/ms11-081

Und dann lässt sich der passende Fix installieren. Moment mal, wo gibt’s den Fix? Hier wirds nun wieder interessant. Zunächst hieß es im offiziellen Blog vom Exchange-Team dass es den Fix nur auf telefonische Anfrage bei Microsoft mit der Referenz auf den (noch nicht veröffentlichten) KB-Artikel KB 2624899 gibt. Wie üblich kostet das nichts und ist auch nicht weiter dramatisch, anrufen, sagen dass man einen Hotfix benötigt, KB-Artikel und Emailadresse angeben, Link bekommen, fertig. Dann wurde ein direkter Download-Link veröffentlicht, aber aktuell ist dieses Update vom Blog wieder entfernt?!

Also der offizielle Weg lautet bei Microsoft anrufen und nach dem Hotfix für KB 2624899 fragen.

Oder halt mal diesen Link ausprobieren..

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2624899

Bei mir hat’s grad eben geklappt, ich geh’ mal davon aus dass sich daran auch nichts ändern wird.

Der Fix ist nun im Update MS11-099 enthalten, dieser ist über Microsoft Update zu erhalten, hiermit wird das Problem dann gelöst.

• http://technet.microsoft.com/en-us/security/bulletin/ms11-099

Hier wäre dann noch der Verweis auf den offiziellen Blog-Eintrag und den zugehörigen KB-Artikel:

• http://blogs.technet.com/b/exchange/archive/2011/10/17/a-fix-for-the-interoperability-issues-between-exchange-2007-and-2010-emc-and-ie9-is-now-available.aspx
• http://support.microsoft.com/kb/2624899

So, also wie geht das nun. Zunächst wird eine entsprechende Policy erstellt und mit den URLs versehen:

New-CsClientPolicy -Identity „SharepointSearch“

Wie lauten die benötigten URLs? das wären folgende, wobei das abhängig von der Umgebung und der Sprache des Systems ist:

SPSearchInternalURL : http://portal/_vti_bin/search.asmx

SPSearchCenterInternalURL : http://portal/SearchCenter/Seiten/peopleresults.aspx

Die interne URL zeigt auf den internen Namen der Sharepointinstallation, wobei darauf zu achten ist ob ein FQDN verwendet wird oder nicht. Welcher Name richtig ist hängt von der Konfiguration des Sharepoint ab, genauer gesagt von den Namenszuordnungen. Also genau so eingeben die der Sharepoint auch im Browser angesprochen wird, dann ist man hier auf der sicheren Seite.

Die externe URL zeigt auf den Namen unter welchem der Sharepoint von extern zu erreichen ist, falls er das ist. Denkbar ist ja eine Veröffentlichung über das TMG. Hier in diesem Beispiel sind interne und externe URLs gleich da der Zugriff von extern über DirectAccess geregelt ist.

Set-CSClientPolicy –Identity “SharepointSearch” –SPSearchInternalURL “http://portal/_vti_bin/search.asmx” –SPSearchCenterInternalURL “http://portal/SearchCenter/Seiten/peopleresults.aspx”

Nach dem Erstellen der Policy muss diese natürlich noch zugewiesen werden, das geht in den Eigenschaften des entsprechenden Benutzers:

Das wars an Konfiguration erstmal. Vom Lync abmelden und neu anmelden, so wird die neue Policy sofort per ‘inband Provisioning’ übernommen. Noch schnell schauen ob die URLs auch gesetzt wurden. Hierzu die Konfigurationsinformationen öffnen – wie bei Outlook auch geht das mit gedrückter STRG-Taste und einem Rechtsklick aufs Tray-Symbol:

Das war ja einfach!

Ja ne, beinahe.. Zumindest bei mir hats nicht geklappt. Die Suche wird zwar angeboten, schlägt dann aber fehl:

Fehler bei der SharePoint-Personensuche aufgrund einer falsch formatierten Abfrage.

Ja moment mal, wie kann die Abfrage falsch formatiert sein, wo der Lync-Client diese doch selber erstellt hat?

Erster Schritt, mal einen Blick in die Logfiles vom IIS auf dem Sharepoint werfen. Um zu überprüfen ob die Anfrage dort ankam und auch verarbeitet werden konnte.

2011-10-15 17:10:53 W3SVC1474160000 192.168.0.0 POST /_vti_bin/search.asmx – 80 Domain\user 192.168.0.0 C/4.0.7577.314+(Microsoft+Lync+2010) 200 0 0

Ja, das hat geklappt. Woran man das erkennt? Nun, es wurde die Such-Anfrage per HTTP-POST an die korrekte URL übergeben und der Server hat dies mit Status 200 (ok)beantwortet.

Im Ereignisprotokoll ist auch nichts zu finden, wie auch, es gab ja keinen Fehler. Also nächster Schritt, eine Analyse des HTTP-Datenverkehrs muss her.

Wenn man sich den Datenverkehr dann im Sniffer anschaut, findet man im HTTP POST folgendes XML-Konstrukt. (Ich hab’ im Wireshark den Datenverkehr aufgezeichnet, dann nach Port 80 gefiltert und den passenden TCP-Datenstrom rausgesucht [follow TCP-Stream]. Hier dann den passenden Bereich kopieren und als .xml speichern. So kann man sichs dann anschauen.. Wenns Interesse gibt wie man sowas mit Wireshark analysiert kann ich dazu gern mal was schreiben, bitte Info!)

<?xml version=“1.0″ encoding=“utf-8″ ?>

-<soap:Envelope xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance“ xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ xmlns:soap=“http://schemas.xmlsoap.org/soap/envelope/“>

.

-<soap:Body>

..

-<Query xmlns=“urn:Microsoft.Search“>

…

<queryXml><QueryPacket xmlns=’urn:Microsoft.Search.Query’> <Query> <SupportedFormats> <Format>urn:Microsoft.Search.Response.Document:Document</Format> </SupportedFormats> <Context> <QueryText language=’de-DE’ type=’string’>lync scope:People</QueryText> </Context> <ResultProvider>SHAREPOINTSEARCH</ResultProvider> <Range> <StartAt>1</StartAt> <Count>21</Count> </Range> <Properties> <Property name=“preferredname“ HitHighLight=“true“/> <Property name=“jobtitle“ HitHighLight=“true“/> <Property name=“department“ HitHighLight=“true“/> <Property name=“officenumber“ HitHighLight=“true“/> <Property name=“workemail“ HitHighLight=“true“/> <Property name=“responsibility“ HitHighLight=“true“/> <Property name=“sipaddress“ HitHighLight=“true“/> <Property name=“pastprojects“ HitHighLight=“true“/> <Property name=“interests“ HitHighLight=“true“/> <Property name=“memberships“ HitHighLight=“true“/> <Property name=“aboutme“ HitHighLight=“true“/> <Property name=“hithighlightedsummary“/> <Property name=“hithighlightedproperties“/> <Property name=“path“/> <Property name=“description“/> <Property name=“write“/> <Property name=“rank“/> <Property name=“size“/> </Properties> <RelevanceModel>D9BFB1A1-9036-4627-83B2-BBD9983AC8A1</RelevanceModel> <TrimDuplicates>true</TrimDuplicates> <IgnoreAllNoiseQuery>true</IgnoreAllNoiseQuery> <ImplicitAndBehavior>true</ImplicitAndBehavior> <IncludeRelevanceResults>true</IncludeRelevanceResults> <IncludeSpecialTermResults>true</IncludeSpecialTermResults> <IncludeHighConfidenceResults>true</IncludeHighConfidenceResults> <EnableNicknames>true</EnableNicknames> <EnablePhonetic>true</EnablePhonetic> </Query></QueryPacket></queryXml>

..

</Query>

.

</soap:Body>

</soap:Envelope>

Und erhält folgende Antwort:

<?xml version=“1.0″ encoding=“utf-8″ ?>

-<soap:Envelope xmlns:soap=“http://schemas.xmlsoap.org/soap/envelope/“ xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance“ xmlns:xsd=“http://www.w3.org/2001/XMLSchema“>

-<soap:Body>

-<QueryResponse xmlns=“urn:Microsoft.Search“>

<QueryResult><ResponsePacket xmlns=“urn:Microsoft.Search.Response“><Response domain=“"><Status>ERROR_BAD_SCOPE</Status><DebugErrorMessage>Der Bereich ist in der Abfrage nicht vorhanden.</DebugErrorMessage></Response></ResponsePacket></QueryResult>

</QueryResponse>

</soap:Body>

</soap:Envelope>

Fehler ist also ERROR_BAD_SCOPE.

Und nu?!

Ich bin nun wirklich kein Sharepoint-Spezialist, sondern versuche nur mehr mit mal anschauen die Dinge zu verstehen. Also, mal das XML-Konstrukt zerlegen, hier findet man den Such-String (lync) und auch den zugehörigen Scope:

<QueryText language=’de-DE’ type=’string’>lync scope:People</QueryText>

So, was hats nun mit dem Scope auf sich? Weil der scheint ja grad’ eben zu stören und nicht zu passen.. Mal auf dem Sharepoint nachsehen, vielleicht klappt die Suche dort ja schon auch nicht, und es hat gar nichts mit Lync zu tun. Solls ja geben, sowas.

Also im Suchcenter, genauer in der Personensuche mal ausprobieren was dann passiert:

http://portal/SearchCenter/Seiten/peopleresults.aspx

Klappt, ich werde gefunden:

So what?

Moment mal! Wenn man im Suchcenter direkt sucht, gibt’s ein Dropdown-Feld:

http://portal/SearchCenter/Seiten/default.aspx

Hier kann man nach „Personen“ suchen, aber nicht nach „People“. Obs das am Ende ist? Englisch-Deutsches Kommunikationsproblem? Im Sharepoint wird nach den String ‘lync’ gesucht, aber mit der Angabe er solle nur nach ‘people’ suchen. Und Sharepoint sagt dann was? Einen Scope ‘people’ kenne ich nicht!

Also einen neuen Scope anlegen. Aber wo geht das? Nach ein wenig Suchen bin ich dann draufgekommen, das gibt’s in der Zentraladministration, in der Verwaltung der gemeinsamen Dienste:

Hier kann man dann im Bereich Suchverwaltung

Einen Bereich unterhalb Abfragen und Ergebnisse erstellen:

Da gibt’s dann die bekannten aus dem Dropdown, wir sind also richtig:

Hier kann man den Suchbereich Personen kopieren:

Und in ‘People’ umbenennen:

So, nun heißts ein paar Minuten warten, bis die Aktualisierung durchgeführt wurde…

Und schon klappts mit dem Suchen und dem Finden:

Damit die Änderung unmittelbar übernommen wird, noch schnell ein IISReset auf dem Sharepoint – wobei sich das in einer produktiven Umgebung unter Tags ja eher nicht eignet…

Wie gesagt, ich bin jetzt nicht so der Sharepointspezialist, wenn jemand einen anderen, vielleicht eleganteren Weg kennt, bin ich gerne offen dafür!

Achso, ja klar. Damit das ganze dann Sinn macht sollten die Daten im AD und in der MySite (Meine Website) einigerpassen gepflegt sein, weil sonst klappt zwar die Anbindung an Sharepoint, aber es gibt halt nix zum finden.

Ist doch eigentlich gar nicht so schwer, oder? Also wenn man mal weiß an welchen Schrauben man in welcher Richtung und wie weit drehen muss..

Ich wollte gerade eben in den letzten Eintrag zum Thema Exchange 2010 RU5 verfügbar einen Hinweis mit einbauen was bei der Installation zu beachten ist. Allerdings gibt’s da einige Punkte, nicht alle treffen für jede Installation zu, aber insgesamt erscheint’s mir dann doch sinnvoller das einmal separat aufzudröseln.

Here we go.

Wie kommt man ans Update?

Am einfachsten (und meine ganz klare Präferenz!) ist der Download übers Download Center, gerne über den direkten Link oder aber auch über eine Suche nach exchange 2010 service pack 1.

Warum nicht über Microsoft Update installieren, wo’s da doch so schön angeboten wird? Nun, zum einen dauert’s immer ne Weile bis die Updates dort dann auch verfügbar sind, und zum andren werden auf Mailboxservern welche Mitglied einer DAG sind die Updates dort nicht erkannt. Drum lieber der sichere Weg über den manuellen Download.

Erster Schritt, das Ding besorgen, wäre also erledigt, quasi abgehakt.

Weiter geht’s mit der eigentlichen Installation. Hier sind es nun wieder ein paar Details auf die es ankommt, jedes mit einer Bedingung ‘trifft das auf die Umgebung zu?’ verknüpft:

Exchangeserver ohne direkten Zugang zum Internet (also kein Surfen möglich)

In diesem Fall wird der Installationsprozess, der eh schon eine ganze Zeit lang läuft, im Schritt “Creating Native images for .Net assemblies.” bzw. “Erstellen von systemeigenen Abbildern für.NET-Assemblys” scheinbar hängen bleiben. Tatsächlich ist dem nicht so, jedoch versucht das System relativ oft eine URL aufzurufen um eine Zertifikatssperrliste (CRL) abzurufen. Da der Aufruf der Seite http://crl.microsoft.com/pki/crl/products/CodeSigPCA.crl mangels Internetverbindung aber nicht klappt wird bei jedem Assembly auf den Timeout gewartet. Und das dauert und dauert und dauert…

Dagegen kann man aber etwas tun, und zwar in den Einstellungen im InternetExplorer. Hier gibt es in den Internetoptionen im Reiter ‘Erweitert’ im Abschnitt ‘Sicherheit’ den Haken ‘Auf gesperrte Serverzertifikate überprüfen*’. Diesen gilt es vor Beginn der Installation zu entfernen und anschließend wieder zu setzen:

Dann geht das insgesamt ein wenig schneller. Es wird immer noch eine Weile dauern, aber daran lässt sich dann nicht weiter machen – das hat dann auch nichts mehr mit der Internetverbindung zu tun, sondern ist eben überall so.

Anpassungen am Design von OWA

Es ist ja durchaus machbar die Seiten vom OWA (beispielsweise die logon.aspx) anzupassen und mit dem eignen Firmenlogo, der Telefonnummer vom Support oder der privaten Telefonnummer vom Exchangeadminkollegen zu versehen. Wie das geht ist hier beschrieben, also nicht das mit der privaten Telefonnummern, sondern das mit der Anpassung ganz grundsätzlich.

Allerdings ist es nun so dass im Rahmen des Updateprozesses diese Dateien möglicherweise ausgetauscht werden und die Anpassungen dann verloren sind. Gegen den Umstand als solchen lässt sich leider nichts machen, man ist daher gut bedient vor Begin des Updates eine Sicherung der angepassten Dateien durchzuführen. Die Dateien befinden sich allesamt im Installationspfad vom Exchange in folgendem Unterordner \V14\Client Access\OWA\\themes\base – diesen einfach komplett kopieren, dann ist man erstmal auf der sicheren Seite. Die Sicherung sollte man hinterher aber nicht einfach wieder zurückkopieren, sonst hat man ja die alten Dateien im System, was wirklich keine gute Idee wäre. Statdessen muss man sich lediglich an die natürlich vorbildlich geführte Dokumentation der Änderungen halten und diese in den neuen Dateien wieder nachtragen. Oder halt zu Fuß vergleichen und die Anpassungen wieder nachtragen, sowas in der Richtung.

Verwendung von CAS-CAS Proxying

CAS-CAS Proxying? wasn das nun schonwieder? Nun, man kann ja durchaus mehrere Standorte haben und möglicherweise haben nicht alle eine direkte Verbindung ins Internet. In einem solchen Fall kann man Exchange zur Verwendung des CAS-CAS Proxying Szenarios konfigurieren. Die Anfragen aus dem Internet landen dann auf dem CAS-Server welcher in der ‘Internet-Facing’ Site steht und werden an den weiteren CAS-Server im anderen Standort weitergeleitet.

In einem solchen Szenario sollte immer mit der ‘Internet-facing’ Site begonnen werden.

Interims Updates

Falls Interims Updates installiert sind, falls das der Fall ist wüsstet ihr das – die gibts nicht einfach so sondern nur auf vielfachen Wunsch beim Microsoft Support bzw. bei speziellen Probleme wie dem Drama ums RU4 – müssen diese vor der Installation des nächsten Rollup Updates entfernt werden. Denn der Fix des Interims Update ist im Rollup dann ja auch enthalten.

Forefront als Email Virenscanner

Häufig, vielleicht sogar sehr häufig, wird auf Exchange dann ja auch Forefront als Emailvirenscanner eingesetzt. Also Forefront Protection for Exchange (FPE). Hierbei gilt es unbedingt zu beachten die Kopplung von FPE an Exchange vor Begin der Installation aufzuheben:

fscutility /disable

und nach der Installation wieder herzustellen:

fscutility /enable

Das ‘fscutility’ ist im Installationsverzeichnis der FPE zu finden, also i.d.R. hier: C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server

Denkt man nicht dran kann es durchaus vorkommen dass nach Installation des Updates / Rollup die Dienste Exchange-Informationsspeicher (MSExchangeIS) und/oder der Exchange-Transport (MSExchangeTransport) nicht mehr starten. Und das ist dann schon eher nachteilig für die gesamte Funktionalität vom Exchange.

Update hierzu, lt. aktuellen Kommentaren im offiziellen Exchange Team Blog erfordern ‘aktuelle’ Versionen der FPE diesesn manuellen Schritt nicht mehr:

@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.

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

UAC auf dem Server aktiviert

Ich persönlich neige ja dazu die User Account Control (UAC) auf den Servern auszuschalten. Das ist eigentlich nicht im Sinne des Erfinders und eben insbesondre aus Sicherheitsaspekten nicht zu empfehlen, aber bequemer ist’s halt schon… Nunja, wenn die UAC aktiviert ist gibt’s bei der Installation der Updates noch etwas zu beachten. Ja klar, das Update als Admin ausführen, was erzähl ich hier… Ja schon aber!. Ja, natürlich muss die Installation in einem administrativen Kontext erfolgen, aber das reine „ausführen als Admin“ reicht nicht unbedingt. Zumindest gibt’s hier und da den Fall dass die Installation erst dann erfolgreich verläuft wenn diese aus einer administrativen Eingabeaufforderung heraus gestartet wurde. Fällt aktuell in die Kategorie ‘muss man wissen’, zum verstehen warum das so ist bin ich noch nicht gekommen. Sobald das aber der Fall ist gibt’s n Update hierzu!

That’s it.