Installation der SCOM- und SCSM Konsole via Configuration Manager
Montag, 25. Januar 2010, 11:45
Abgelegt unter: Anleitungen | Tags: , , , ,

Bisher fehlten noch die Konsolen für den Operations Manager und den Service Manager auf meinem Arbeitsplatz-PC. Natürlich wäre es möglich, diese manuell zu installieren, doch für was hat man ja den Configuration Manager im Einsatz? Ich habe mich also gefragt, wie man die beiden Konsolen für den Service Manager und den Operations Manager mit Hilfe des Configuration Manager auf die PCs verteilen kann. Und die Antwort darauf ist erfreulich einfach…

Installation der Service-Manager-Konsole via SCCM

Die automatisierte Installation der Service-Manager-Konsole ist sehr einfach zu bewerkstelligen:

  • Man nehme die Datei „sm.msi“ aus dem Ordner „<Pfad zur SCSM-Software>\SMCDImage_x86\Setup\Server“ und lege sie in einem passenden Source-Ordner für den Configuration Manager bereit.
  • Man erstelle ein neues Anwendungspaket im SCCM, gebe den entsprechenden Source-Ordner an und lege das Paket auf die gewünschten Distribution Points.
  • Man erstelle ein neues Program in diesem Anwendungspaket und definiere darin das Requirement, dass man diese Paket nur auf x86-Systemen installieren dürfe. Die Kommandozeile für die Installation lautet (selbstverständlich ohne Zeilenumbruch) :


msiexec /i SM.msi INSTALL_SM_SERVER=0
INSTALL_SM_DATABASE=0 INSTALL_SM_CONSOLE=1
MGSERVER=<Service Manager Management Server> /qb-

  • Man advertise diese Program an die gewünschten Clients, z.B. auch an den eigenen PC.

Ist die Installation auf dem PC durchgelaufen, kann man die Konsole starten und muss dann beim ersten Start den Namen des Service Manager Management Servers angeben. Das wärs. Hat auf meinem Windows 7 x86 PC anstandslos funktioniert. Hat man x64-basierte PCs, dürfte das Vorgehen analog sein: SM.msi aus dem x64-Ordner nehmen, … Sollte man die Konsole wieder entfernen wollen, reicht das übliche „msiexec /x sm.msi“.

Installation der Operations-Manager-Konsole via SCCM

Auch die Installation der Operations Manager Konsole ist einfach:

  • Man nehme den Ordner „i386“ aus Ordner „Server“ im Installationspfad der Operations Manager 2007 R2 Software und lege diesen in einem passenden Source-Ordner für den Configuration Manager bereit.
  • Man erstelle ein neues Anwendungspaket im SCCM, gebe den entsprechenden Source-Ordner an und lege das Paket auf die gewünschten Distribution Points.
  • Man erstelle ein neues Program in diesem Anwendungspaket und definiere darin das Requirement, dass man diese Paket nur auf x86-Systemen installieren dürfe. Die Kommandozeile für die Installation lautet (selbstverständlich ohne Zeilenumbruch) :


msiexec /i MOM.msi /qb- ADDLOCAL=MOMUI
ROOT_MANAGEMENT_SERVER_DNS=<FQDN des Servers>

  • Man advertise diese Program an die gewünschten Clients, z.B. auch an den eigenen PC.

Ist die Installation auf dem PC durchgelaufen, kann man die Konsole starten. Auch dies hat auf meinem Windows 7 x86 PC anstandslos funktioniert. Hat man x64-basierte PCs, muss man einfach den Ordner „AMD64“ aus dem Ordner „Server“ kopieren und analog vorgehen. Zur Entfernung der Konsole reicht das einfache „msiexec /x MOM.msi“.

Beobachtungen

So weit, so gut. Spannender wird die Angelegenheit, wenn man beide Konsolen auf dasselbe System installiert:

  • Installiert man zuerst die Konsole für den SCOM 2007 R2 und dann erst die Konsole für den Service Manager Beta 2, ist alles bestens. Beide Konsolen funktionieren wunschgemäss.
  • Installiert man jedoch zuerst die Konsole für den Service Manager und dann erst diejenige für den Operations Manager, dann funktionieren zwar beide Konsolen, doch bringt dies (zumindest bei auf meinen Systemen, dies aber reproduzierbar) etwas ungewohnte Farbe in den Admin-Alltag…

Unerwartete Farbe in der SCOM-Konsole

Zudem: Deinstalliere ich die Service-Manager-Konsole, lässt sich die Operations-Manager-Konsole nicht mehr starten; diese crasht dann bei jedem weiteren Startversuch.

Fazit

Die Installation der beiden Konsolen via SCCM funktioniert grundsätzlich problemlos, nur sollte man

  • zuerst die Operations Manager Konsole und dann erst die Service Manager Konsole installieren
  • bei der Deinstallation der Service Manager Konsole darauf achten, dass man danach noch eine funktionierende Operations Manager Konsole vorfindet…


Installation MS System Center Service Manager – Teil 4 – „System Center Configuration Manager Connector“
Dienstag, 29. Dezember 2009, 17:46
Abgelegt unter: Anleitungen | Tags: , , ,

Nachdem gestern die Anbindung des Service Manager an das Active Directory problemlos geklappt hat, ist heute nun der System Center Configuration Manager an der Reihe.

Im SCSM-Blog der belgischen System Center User Group finde ich den Hinweis, dass das dafür benötigte Connector Account Mitglied der „smsdbrole_extract“ und der „db_datareader“ Gruppen der SMS-Datenbank sein müsse. Das sagt mir im Moment mal leider gar nichts, denn ich kenne keine entsprechenden Einträge in der SCCM-Konsole. Ich schaue deshalb mal mit dem „SQL Server Management Studio“ in die Site-Datenbank rein und werde tatsächlich fündig: In der Site-Datenbank finde ich die beiden Bezeichnungen unter „Security“ -> „Roles“ -> „Database Roles“.

Ich erstelle deshalb im Active Directory ein passendes Service Account. Dieses kann ich nun als erstes dem SQL Server bekannt machen, indem ich unter der entsprechenden Datenbankinstanz -> „Security“ -> „Logins“ ein neues Login mit dem entsprechenden AD-Loginnamen vom Typ „Windows Authentication“ anlege. Unter „Server Roles“ ist bereits „public“ vorgegeben, unter „Status“ ist die Erlaubnis für das Verbinden zur Datenbank erteilt und das Login ist aktiviert.

Als nächstes kann ich nun bei der Site-Datenbank als User definieren, indem ich in der Site-Datenbank unter „Security“ -> „Users“ einen neuen Benutzer anlege. Hier kann ich nun beim Feld „Login Name“ nach dem betreffenden Benutzer suchen; als „User Name“ verwende ich wieder denselben Wert wie er nun beim „Login-Name steht. Unten in der Liste „Database Role Membership“ kann ich nun die beiden gewünschten Rollen „smsdbrole_extract“ und „db_datareader“ aktivieren.

Da nun die Prerequisites erfüllt sein sollten, wechsle ich nun auf unseren Service Manager. In der Konsole finde ich im Bereich „Administration“ unter „Getting started“ im Kasten „Create Connectors“ den Link „Create a Configuration Manager connector“, den ich nun mal anklicke. Damit wird der „System Center Configuration Manager Connector Wizard“ gestartet, der mir seine Willkommensseite präsentiert. Nach einem ersten Klick auf „Next“ werde ich nach einem Namen und einer Beschreibung gefragt, die ich passend angebe und dann wieder auf „Next“ klicke.

Nun werde ich nach einem Management Pack gefragt, wo dieser Connector gespeichert werden soll. Die einzige Auswahlmöglichkeit ist das Management Pack „System Center COnfiguration Manager Connector Configuration“, das ich mit einem Klick auf „Next“ übernehme.

Nun wird es spannend: Auf der nächsten Seite des Wizard sind nun die Angaben zur Datenbank notwendig. Als „Database Server Name“ trage ich unsere Named Instance in der Form „<Servername>\<Instancename>“ ein, als „Database Name“ das übliche „SMS_<Sitecode>“. Im Bereich „Credentials“ klicke ich nun beim „Run as Account“ auf „New…“ und erstelle damit ein neues „Run As Account“. Als „Display Name“ wähle ich „SCCM Connector Account“, trage eine passende Beschreibung ein und ergänze die entsprechenden Angaben zum AD-Konto. Ein Klick auf „OK“ und schon ist das neuerstellte Konto als „Run As“-Konto definiert. Erleichtert lese ich nach dem Klick auf „Test Connection“: „The connection to the server was successful.“

Auf der nächsten Seite des Assistenten kann ich nun die zu synchronisierende Collection wählen. Dabei werden mir alle Collections angezeigt, die mindestens ein Mitglied besitzen. Erfreut stelle ich mit einem kurzen Seitenblick zur SCCM-Konsole fest, dass die angezeigten Zahlen der enthaltenen Computer den Angaben im SCCM entsprechen: Wenn das kein gutes Omen ist! Nachdem ich „All Systems“ ausgewählt habe, klicke ich auf „Next“.

Nun muss ich noch den Schedule definieren, wann dieser Connector ausgeführt werden soll. Zur Auswahl wird mir „Every Day“ oder ein expliziter Wochentag angeboten, was einer wöchentlichen Synchronisierung entsprechen würde. Als Zeitpunkt kann ich jeweils eine volle Stunde wählen. Ich entscheide mich für täglich abends um 23 Uhr. So sollten die Veränderungen eines Tages im Configuration Manager am nächsten Tag im Service Manager nachgeführt sein.

Nach dem nächsten „Next“ wird mir nun noch das Summary präsentiert, worauf ich auf „Create“ klicke. Wenige Sekunden später erhalte ich die Meldung, dass ich den Wizard erfolgreich abgeschlossen hätte, den ich nun mit einem Klick auf „Close“ schliesse.

Zurück in der Konsole, nagiviere ich zu den „Connectors“ und sehe dort den neu erstellten Connector. Ich wähle diesen aus und klicke auf „Synchronize Now“. Dies wird sogleich bestätigt mit einer Meldung, dass der entsprechende Request abgesetzt worden sei. Der Status wird des Connectors wird nun als „Running“ angezeigt, zudem kann ich mitverfolgen, wie der Wert „Percentage“ langsam aber sicher steigt.

Etliche Zeit später – die Synchronisation grosser Produktionsumgebungen kann offenbar durchaus Stunden dauern – kann ich nun lesen: Status „Finished Success“, Percentage „100%“. Ich wechsle deshalb in den Abschnitt „Configuration Items“. Und siehe da: Nun sind zu den von SCCM verwalteten Computern detaillierte Informationen vorhanden.

Wenn doch bloss immer alles so einfach wäre und so reibungslos funktionieren würde…



Installation MS System Center Service Manager – Teil 2 – Installation „Service Manager Data Warehouse Management Server“
Donnerstag, 24. Dezember 2009, 09:46
Abgelegt unter: Anleitungen | Tags: , , , ,

Nachdem ich – wie im letzten Beitrag beschrieben – erfolgreich den „Service Manager Management Server“ auf dem ersten Server installieren konnte, möchte ich nun auf dem zweiten Server den „Service Manager Data Warehouse Management Server“ installieren. Da ich herausgefunden habe, dass sich eine Service Manager Installation und ein bereits vorhandener Operations Manager Agent gegenseitig in die Quere kommen, entferne ich zuerst auch beim zweiten Server den SCOM-Agent über die SCOM-Konsole, danach logge ich auf diesem Server ein. Als erstes installiere ich sogleich via Server Manager das Feature „Microsoft .NET Framework 3.5.1“ mitsamt allen Dependencies.

Der erste Installationsversuch des „Service Manager Data Warehouse Management Server“ schlägt sehr schnell fehl, es fehlen die SQL Reporting Services, die zuerst noch installiert werden müssen.

Also habe ich flugs die SQL Server 2008 Scheibe eingelegt und darauf Setup gestartet. Im „SQL Server Installation Center“ muss nun links in der Navigation auf „Installation“ geklickt werden, dann kann der Installationswizard über den Link „New SQL Server stand-alone installation or add features to an existing installation“ gestartet werden. Darauf musste ich zuerst auch einmal kommen, denn wenn man als Nicht-SQL-Profi nur die Reporting Services installieren will, kommt man nicht unbedingt auf die Idee, dass man dazu die Installation eines neuen „SQL Server stand-alone“ starten muss.

Als erstes werden nun die „Setup Support Files“ installiert. Dabei wird zuerst das System auf mögliche Probleme abgeklopft, die bei der Installation auftreten könnten, als nächstes muss der Product Key für den SQL-Server eingegeben und der Lizenzvertrag abgenickt werden, danach werden die Setup Support Files installiert; das Ergebnis wird danach angezeigt.

Nun startet das eigentliche SQL Server 2008 Setup. Hier habe ich einzig das Feature „Reporting Services“ angewählt und dann auf Next geklickt. Als nächstes muss man sich entscheiden, ob man die „Default instance“ oder eine „Named instance“ verwenden will. Hier bin bei der „Default instance“ geblieben und habe alle Vorgabewerte übernommen. Im nächsten Schritt werden die „Disk Space Requirements“ angezeigt, die bei mir erfüllt sind, dann muss ich angeben, unter welchem Service Account die Reporting Services laufen sollen, somit folgt hier das übliche Prozedere: Ein neues, passendes Konto im AD generieren und hier dann sogleich eintragen.

Nun folgt der Schritt „Reporting Services Configuration“. Die ersten zwei Auswahlmöglichkeiten sind ausgegraut, die einzige verfügbare dritte Auswahl lautet „Install, but do not configure the report server“. Im Text dazu wird erwähnt, dass man nach abgeschlossener Installation das „Reporting Services Configuration Tool“ verwenden müsse, um den Report-Server zu konfigurieren. Gut, muss ich mir merken.

Nun folgen die üblichen Auswahlen zum „Error und Usage Reporting“, die ich hier mal deaktiviert lasse. Nachdem dann die „Installation Rules“ erfolgreich überprüft worden sind, erhalte ich nun das „Ready to install“. Noch ein kurzer Blick auf das Summary, dann folgt der Klick auf den Knopf „Install“. Zwei Minuten später lese ich „Setup process complete, Reporting Services -> Success“. Es folgt eine letzte Dialogseite, die mir nochmals bestätigt, dass meine „SQL Server 2008 Installation“ erfolgreich abgeschlossen wurde, dann wird der Assistent geschlossen.

Ok, die Reporting Services sind installiert, also zurück zum Service Manager. Halt! Da war doch noch was. Stimmt, die Reporting Services müssen ja noch konfiguriert werden: Der „Reporting Services Configuration Manager“ ist im Startmenü rasch gefunden und gestartet. Dieser will sich nun mit einer Serverinstanz verbinden, die angegebenen Vorgabewerte passen; also „Connect“. In der ersten Ansicht wird mir nun bestätigt, dass der Report Service läuft, zudem sind verschiedene Angaben zur Instanz und SQL-Serverversion aufgelistet. In der Navigationsspalte sind verschiedene Punkte aufgelistet, die mir im Moment noch nicht viel sagen, also sehe ich diese mal der Reihe nach durch:

  • „Service Account“: Hier sehe ich die Infos zum bei der Installation angegebenen Service Account und könnte diese nötigenfalls ändern.
  • „Web Service URL“: Ich sehe eine Warnung, dass der „Report Server Web Service“ nicht konfiguriert sei, aber es wurden netterweise Defaultwerte bereitgestellt, die ich mit „Apply“ übernehmen kann.
  • „Database“: Die Angaben zur „Current Report Server Database“ sind leer. Also klicke ich auf „Change Database“, worauf mir angeboten wird, eine neue Datenbank zu erstellen. Hier trage ich wieder mal den Namen unseres SQL 2008 Clusters ein und teste die Verbindung mit dem vorgeschlagenen „Authentication Type: Current User – Integrated Security“. Funktioniert! Nun erstelle ich eine neue Datenbank im Native Mode, auf die mit den „Service Credentials“ zugegriffen werden soll. Das klappt auf Anhieb, die Angaben zur Datenbank und den Credentials erscheinen danach im „Reporting Services Configuration Manager. Noch ein kurzer Klick auf Apply, dann ist auch dieser Schritt durch.
  • „Report Manager URL“: Hier wird ebenfalls eine Warnung angezeigt, dass das „Report Manager Virtual Directory“ nicht konfiguriert sei. Doch der vorgeschlagene Defaultwert „Reports“ lässt sich mit einem Klick auf Apply übernehmen.
  • „E-mail Settings“: Hier trage ich die Emailadresse ein, die für den Versand verwendet werden soll, und konfiguriere unseren SMTP-Server.
  • „Execution Account“: Hier liesse sich ein zusätzliches Konto definieren, das für den Zugriff auf weitere Datenquellen oder Server verwendet könnte. Ich vermute, dass wir das im Moment nicht benötigen und lasse das mal leer.
  • „Encryption Keys“: Hier lassen sich die Schlüssel verwalten, die zur Verschlüsselung sensibler Daten wie Credentials, Connection Strings usw. verwendet werden.
  • „Scale-out-Deployment“: Hier liessen sich weitere Server hinzufügen, die ihre Daten in derselben Datenbank speichern sollen.

Da ich nun mal alle Punkte in der Navigation durchgegangen bin und nirgends mehr eine Warnung sehe, gehe ich nun davon aus, dass die Reporting Services konfiguriert sind; also klicke ich nun auf Exit.

Nun kann ich mich wieder dem „Service Manager Data Warehouse Management Server“ zuwenden: Beim nächsten Installationsversuch kann ich nun den Namen und die Organisation eingeben und den Lizenzvertrag abnicken. Auch bei diesem Server bleibt das Feld für den Product-Key leer, da für die Beta-Version noch kein Product-Key benötigt wird.

Im nächsten Dialogfenster wird nach dem Installationspfad gefragt; genügend Diskplatz (verlangt wird 1 GB) ist vorhanden. Auch bei diesem Server erhalte ich eine „Memory-Check“-Warnung: Für den Data Warehouse-Server werden ganze 8 GB RAM empfohlen! Auch dieser Server hat nur 2GB Arbeitsspeicher, dennoch lässt sich das Setup fortsetzen.

Nun wird nach den benötigten Datenbanken gefragt. Hier trage ich den Namen unseres SQL2008-Clusters ein und erhalte wenige Augenblicke später die entsprechende Instanz angeboten. Für die Datenbanken ‚Staging and Configuration‘ (DWStagingAndConfig) und ‚Repository‘ (DWRepository) werden sogleich sinnvolle Werte angezeigt; bei der Datenbank ‚Data Mart‘ ist noch ein rotes Kreuz zu sehen. Auch hier kann ich nochmals unseren SQL2008-Cluster angegeben und erhalte umgehend brauchbare Werte. Offenbar liesse sich diese Datenbank problemlos auf einem anderen Server hosten, doch einen zweiten SQL-Server haben wir nicht zur Verfügung. Somit habe ich wiederum die Default Werte übernommen.

Nun wird im nächsten Dialogfeld wiederum nach einem „Management Group Name“ gefragt, wobei explizit ausgeschlossen wird, dass man einen bereits verwendeten Wert erneut wählt. Somit habe ich hier unser offizielles Kürzel, ergänzt durch ‚-DW‘ eingetragen, da ich unser offizielles Kürzel bereits für die Management Group beim Management Server verwendet habe. Zudem wird noch nach einem Benutzer bzw. einer Gruppe gefragt, die als Administrator für diese Management Gruppe amtieren darf; hier habe ich dieselbe Gruppe wiederverwendet, die ich schon bei der Installation des Management-Servers eingetragen habe.

Im nächsten Schritt muss nun der Reporting Server für das Data Warehouse konfiguriert werden. Erfreut stelle ich fest, dass der vorhin installierte Reporting Server erkannt wird und dessen URL als gültig akzeptiert wird.

Nun müssen noch zwei Konti konfiguriert werden: Als Konto für die „Service Manager Services“ habe ich dasselbe Konto verwendet, das ich auch schon bei der Installation des Management Servers angegeben habe; dieses muss lokale Administratorenrechte besitzen, was ich sogleich noch im Computermanagement“ konfiguriere. Für das „Reporting Account“ habe ich wieder einmal flugs ein neues, passendes AD-Konto erstellt und eingetragen.

Jetzt folgen noch die Fragen zum „Customer Experience Improvemend Program“ und zum „Error Reporting“; auch hier wähle ich zweimal „Yes“. Nun wird noch das Summary angezeigt, danach startet die Installation.

Bereits wenige Minuten später heisst es: „Finished. Setup completed successfully.“

Somit sind der „Service Manager Management Server“ und der „Service Manager Data Warehouse Management Server“ installiert. Nun geht es an die Konfiguration des Service Managers, aber das ist etwas für die nächsten Beiträge.



Installation MS System Center Service Manager – Teil 1 – Installation „Service Manager Management Server“
Montag, 21. Dezember 2009, 21:01
Abgelegt unter: Anleitungen | Tags: , ,

Heute habe ich versucht, in unserer Umgebung den System Center Service Manager (öffentliche Beta 2) zu installieren. Hierzu stehen mir zwei Server zu Verfügung, die mit Server 2008 R2 installiert sind. Wie für alle unsere Server üblich, ist darauf bereits McAfee Virusscan 8.7 Patch 2 inkl. ePolicyOrchestrator-Agent installiert. Ebenso ist darauf der SCCM-Client und der SCOM-Agent zu finden.

Den ersten Server will ich als Service Manager Management Server benutzen. Somit logge ich mich auf diesem Server ein und starte das Setup des Service Manager. Sogleich wird angezeigt, dass das „Microsoft .NET Framework 3.5 inkl. SP1“ benötigt werde. Beim Server 2008 R2 lässt sich dieses als Feature hinzufügen, somit hole ich das über den Server Manager sogleich nach, wobei ich alle Dependencies zum Feature mitinstalliere.

Auch der nächste Versuch zur Installation des „Service Manager Management Server“ schlägt fehl, da ein Operations Manager Agent auf diesem Server drauf ist.

Fehlermeldung: SCOM agent is installed.

Ich deinstalliere deshalb den SCOM-Agent über die SCOM-Konsole. Beim nächsten Installationsversuch kann ich nun den Namen und die Organisation eingeben und den Lizenzvertrag abnicken. Das Feld für den Product-Key bleibt leer, da für die Beta-Version noch kein Product-Key benötigt wird. Im nächsten Dialogfenster wird nach dem Installationspfad gefragt und darauf hingewiesen, dass 1 GB freier Diskplatz benötigt werde. Dieser ist glücklicherweise vorhanden. Beim anschliessenden Memory-Check wird bemängelt, dass der Server nur 2GB Arbeitsspeicher habe; empfohlen wären 4 GB. Die Prozessorgeschwindigkeit wird als ok beurteilt. Trotz der „Memory Check“-Warnung lässt sich das Setup fortsetzen.

Nun wird nach der Service Manager Datenbank gefragt. Hier trage ich den Namen unseres SQL2008-Clusters ein und erhalte wenige Augenblicke später die entsprechende Instanz angeboten. Als Database Name wird „ServiceManager“, als Grösse 2000MB vorgeschlagen. Auch die vorgeschlagenen Pfade für den Data- und den Log-File-Ordner passen. Somit akzeptiere ich die Werte und fahre weiter.

Im nächsten Dialogfeld wird nach dem „Management Group Name“ gefragt, für den ich unsere offizielle Abkürzung wähle. Zudem wird noch nach einem Benutzer bzw. einer Gruppe gefragt, die als Administrator für diese Management Gruppe amtieren darf. Flugs erstelle ich eine passende Gruppe im Active Directory und wähle diese dann anschliessend aus.

Nun wird nach einem Domain Account gefragt, unter welchem der System Center Service Manager laufen soll. Dieses muss lokale Administratorenrechte für den gerade zu installierenden Server haben. Auch hier richte ich kurzerhand ein passendes Konto ein und befördere dieses zum lokalen Admin. Danach wird noch nach einem Service Manager Workflow Account gefragt, welches ich ebenfalls im AD definiere und dann angebe.

Jetzt folgen noch die Fragen zum „Customer Experience Improvemend Program“ und zum „Error Reporting“. Da wir hier eine Beta-Version einsetzen, bejahe ich mal beides. Nun wird noch das Summary angezeigt, danach startet die Installation.

Bereits wenige Minuten später lacht mich folgende Meldung an: „Finished. Setup completed successfully.“ Ist das bereits alles? Scheint so, denn unten wird bereits eine Checkbox angeboten: „Open the Service Manager Console when Setup closes“. Na dann: Probieren geht über studieren! Tatsächlich: Kurz nach dem Klick auf „Close“ sehe ich erstmals die Konsole des System Center Service Manager.

Erster Blick auf die Service Manager Konsole

„Getting started“ heisst nun das Motto. So gibt es diverse „required configuration tasks“, die durchlaufen werden müssen, bevor der Service Manager tatsächlich benutzt werden kann. Aber das ist definitiv etwas für den nächsten Beitrag.