Im wieder taucht in den Newsgroups und einschlägigen Foren die Frage auf, ob es möglich ist, Dynamics AX 2009 unter Windows Server 2008 und/oder in Verbindung mit SQL Server 2008 zu betreiben.
Die Antwort auf diese Frage lautet eigentlich „Ja“, zugleich aber auch „Nein“.
Offiziell sind die beiden Produkte zwar noch nicht für die Verwendung mit Dynamics AX 2009 freigegeben, aber prinzipiell funktioniert Dynamics AX 2009 auch mit dieser Systemkonfiguration (Kernfunktionalität).
Allerdings muss auch erwähnt werden, dass der eine oder andere Punkt bei der Installation bzw. beim Betrieb von Dynamics AX 2009 mit Windows Server 2008 und/oder dem SQL Server 2008 für Verwirrung sorgen kann.
So wird, nach erfolgreicher Installation der Basiskomponenten von Dynamics AX 2009 und anschließendem AOS Start, eine Fehlermeldung im Ereignisprotokoll von Windows Server 2008 erzeugt, welche aussagt, dass Dynamics AX 2009 (genauer der AOS) das gewählte Betriebssystem nicht unterstützt.
Ungeachtet dieser Fehlermeldung, läuft der AOS Dienst von Dynamics AX 2009 unter Windows Server 2008 ohne weitere Probleme. Unschön ist nur, dass diese Meldung bei jedem Start des AOS erzeugt wird.
Für die Verwendung des Enterprise Portals bzw. des Rolecenters muss beachtet werden, dass wie im Installation Guide von Dynamics AX 2009 beschrieben, die Sharepoint Services 3.0 mit SP1 verwendet werden müssen, da frühere Versionen nicht richtig unter Windows Server 2008 laufen.
Ein weiterer Punkt der unbedingt beachtet werden sollte, sind die Reporting-Erweiterungen von Dynamics AX 2009.
Eine Installation der Reporting-Erweiterungen ist derzeit leider nur möglich, wenn die Reporting Services des SQL Server 2005 in der Service Pack Version 2 verwendet werden.
Sollen die Reporting Services des SQL Server 2008 verwendet werden, scheitert es schon an der Installation der Reporting-Erweiterungen von Dynamics AX 2009.
Diese lassen sich in einer solchen Systemumgebung erst gar nicht installieren. Das Setup wird durch eine entsprechende Fehlermeldung abgebrochen.
Dies hat zur Folge, dass die Reporting Services des SQL Server 2008 nicht mit Dynamics AX 2009 verwendet werden können.
Gleiches gilt für die Analysis Extensions von Dynamics AX 2009 in Kombination mit den Analysis Services des SQL Server 2008.
Diese lassen sich zwar ohne Problem installieren, aber eine Verarbeitung der Cubes ist nicht möglich, da diese auf Grund von Verarbeitungsfehlern abgebrochen wird.
Schlussendlich bedeutet dies, dass die Verwendung von Windows Server 2008 als Betriebssystem für Dynamics AX 2009 keine Probleme bereiten sollte.
Für die reinen Datenbankdienste von SQL Server 2008 trifft dies ebenfalls zu. In meinen Test konnte ich keinerlei Probleme beim Betrieb mit Dynamics AX 2009 erkennen.
Anderes gilt für die Reporting und Analysis Services von SQL Server2008. Deren Verwendung ist leider noch nicht möglich und es müssen weiterhin die Reporting und Analysis Services des SQL Server 2005 verwendet werden um alle möglichen Funktionalitäten von Dynamics AX 2009 zur Verfügung stellen zu können.
Wie bereits im diesem Artikel "Fehlermeldung beim Starten des Microsoft Dynamics AX Clients" beschrieben, kann es zu Fehlermeldungen beim Starten des Dynamixs AX 4.0 Client kommen.
Eine weitere Fehlermeldung, welche erzeugt werden kann ist "Incompatible ext. version".
Es ist auch möglich, dass diese sogar mehrfach ausgegeben wird.
Grund hierfür ist meist ein Problem mit der TAPI-Integartion des CRM Moduls, bzw. genauer gesagt, ein Problem mit den eingestellten Wählregeln/Standorte der Windows Telefon- und Modemoptionen.
Die Behebung des Fehlers ist eigentlich ganz einfach.
- Wenn die TAPI-Integration nicht genutzt wird, kann diese deaktiviert werden.
Wie dies genau geht kann in diesem Artikel "Fehlermeldung beim Starten des Microsoft Dynamics AX Clients" nachgelesen werden.
- Wenn die TAPI-Integration verwendet werden soll, muss ein neuer Standort in den Windows Telefon- und Modemoptionen erstellt werden.
Das Erstellen eines neuen Standorts erfolgt über "Start -> Systemsteuerung -> Telefon- und Modemoptionen" auf dem jeweiligen Clientcomputer (pro Benutzer).
Dort sollte, wenn vorhanden, ein bestehender Standort gelöscht werden und ein neuer angelegt werden.
Manchmal ist es möglich, dass beim Starten des Microsoft Dynamics AX 4.0 Clients eine oder meherer Fehlermeldungen in einem Infolog-Fenster ausgegeben werden.
Diese Fehlermeldung könnten z.B. "Corrupted ini file" sein.
Die große Frage ist nun, woher kommt diese Fehlermeldung bzw. wodurch wird diese erzeugt.
Leider ist die Fehlermeldung, welche im Ereignisprotokoll gefunden werden kann, meist auch nicht besonders hilfreich.
Sollten solche, eher unerklärlichen Fehlermeldungen beim Starten des Dynamics AX Client ausgegeben werden, lohnt sich oft ein Blick in die Systemkonfiguration, welche über Verwaltung, Einstellungen, System, Konfiguration aufgerufen werden kann.
Der Grund für diese Fehlermeldung könnte die aktivierte Telefonieintegration des CRM Moduls sein.
Wird diese deaktiviert, sollte die Fehlermeldung nicht mehr erzeugt werden.
Wenn bei der Entwicklung mit Microsoft Dynamics AX 4.0 die Quellcodeverwaltung mittels Visual SourceSafe 2005 eingeschaltet wurde, besteht die Möglichkeit einzelne Versionen eines Objekts miteinander zu vergleichen.
Hierbei kann es aber bei einer "ungünstigen" Konfiguration des lokal Repository-Verzeichnisses sein, dass bei einem Vergleich von zwei Objektversionen die Fehlermeldung "Fehler: Fortsetzen nicht möglich" ausgegeben wird.
Diese Fehlermeldung wird immer erzeugt, wenn sich das lokale Repository-Verzeichnis und das Verzeichnis, in dem die temporären Internetdateien (Temporary Internet Files) gespeichert werden, nicht auf der gleichen Partition (Datenträger) befinden.
Beispiel:
Ordner der Temporary Internet Files = C:\Dokumente und Einstellungen\UserXY\Lokale Einstellungen\Temporary Internet Files
Ordner des lokalen Repositories = D:\VSSRepository\Test
-> Die Fehlermeldung wird ausgegeben.
Ordner der Temporary Internet Files = C:\Dokumente und Einstellungen\UserXY\Lokale Einstellungen\Temporary Internet Files
Ordner des lokalen Repositories = C:\VSSRepository\Test
-> Die Fehlermeldung wird nicht ausgegeben und der Versionvergleich funktioniert problemlos.
Dieses Problem wird durch ein Update für Visual SourceSafe 2005 behoben. Es empfiehlt sich, bei Verwendung der Quellcodeverwaltung mit Visual SourceSafe 2005 als VC-System, dieses Update einzuspielen.
Einen ersten Ausblick auf die "neuen" Quellcodeverwaltungsfeatures in Microsoft Dynamics AX 5.0 zeigt der Screencast "Version control in MorphX" auf Channel9.
http://channel9.msdn.com/Showpost.aspx?postid=367024
Ich zitiere:
"This screencast is a preview of the version control system integration options in the next release of MorphX - the IDE of Dynamics AX.
It shows a side-by-side comparison of the integration options with Team Foundation Server, Visual Source Safe, and MorphX VCS.
The latter is a simple, yet powerful alternative without any additional infrastructure requirements. The last half of the screencast gives a demonstration of MorphX VCS."
Durch die neuen Features die MorphX VCS mit sich bringt, sowie die Möglichkeit Visual Studio Team System, oder genauer der Team Foundation Server, (nicht nur) als Quellcodeverwaltung zu verwenden, sollte nun für jeden ein "passendes" Quellcodeverwaltungsystem bereit stehen.
Vielen Dank an dieser Stelle an Michael Fruergaard Pontoppidan (http://blogs.msdn.com/mfp/default.aspx) für diesen und die bisherigen Screencasts über Microsoft Dynamics AX.
Erhält man bei seiner täglich Arbeit die Fehlermeldung „Ein Befehl der Datendefinitionssprache kann nicht für () ausgeführt werden. Die SQL Datenbank hat einen Fehler gemeldet.“ oder auf englisch „cannot excecute a data definition language command on (). The SQL database has issued an error.” stellt sich einem meist eine große Hürde in den Weg, weil aus dieser Fehlermeldung nicht eindeutig zu erkennen ist, wo ein Fehler entstanden ist bzw. wieso der Fehler auftritt.
Durch Zufall bin ich drauf gestoßen, wie man genau diese Fehlermeldung produzieren kann und somit Rückschlüsse auf die Ursache des Fehlers schließen kann.
Das Folgende Vorgehen...
- Erstellen eines EDT’s vom Typ „string“ mit dem Namen „MY_BaseId“.
- Verwenden des EDT’s in einer Tabelle (Name: MY_BaseTable).
- Erzeugen von mehreren Datensätzen in der Tabelle.
- Löschen des EDT’s „MY_BaseId“.
- Erstellen eines EDT’s vom Typ „real“ mit dem Namen „MY_BaseId“ (gleicher Name wie der gelöschte EDT vom Typ „string“ hatte).
- Kompilieren oder synchronisieren der Tabelle „MY_BaseTable“.
...ergibt die genannte Fehlermeldung.
Daraus ist zu schließen, dass der Fehler immer Auftritt, wenn der Typ eines vorhandenen EDT’s den bereits eine oder mehrere Tabellen verwenden, geändert wird.
Ich konnte die Fehlermeldung bzw. den Fehler aber nur reproduzieren, wenn die jeweilige Tabelle ein oder mehrere Datensätze enthielt. War in der Tabelle kein Datensatz vorhanden kam es nicht zu der Fehlermeldung.
Um besagten Fehler oder besagte Fehlermeldung zu beheben müssen entweder alle Datensätze in der Tabelle oder die Tabelle selbst gelöscht werden.
Möchte man die schon gepflegten Daten eines Dynamics AX 3.0 System über exportieren/importieren in ein Dynamics AX 4.0 SP1 System übernehmen, wird bei diesem Vorgang leider eine Fehlermeldung erzeugt, dass ein Importieren in das Dynamics AX 4.0 SP1 System nicht möglich ist, da die Daten aus einem älteren System stammen.
Dies ist soweit auch in Ordnung, da sich Tabellen und Felder von Version 3.x zu Version 4.0 SP1 verändert haben (Namensänderungen, Feldergänzungen, etc.).
Da bei einigen Tabellen aber nur Felder weggenommen wurden, könnte man theoretisch die Daten aus dem „alten“ 3.x System übernehmen. Ein Beispiel hierfür ist der Kontenplan (LedgerTable).
Damit dies funktioniert muss aber eine Änderung an der aus dem Dynamics AX 3.x System exportierten „.def“ Datei vorgenommen werden. Die erste Zeile der „.def“ Datei muss so bearbeitet werden, dass diese wie folgt lautet:
Wenn beim Export als Dateityp „Binär“ gewählt wurde:
"EXPFORMAT VER. 4.01","Binary"
Wenn beim Export als Dateityp „Komma“ gewählt wurde:
"EXPFORMAT VER. 4.01","Comma"
Wurde die „.def“ Datei entsprechend angepasst, kann es zwar sein, dass beim Import Fehlermeldungen über nicht vorhandene Felder erzeugt werden aber der Importvorgang an sich funktioniert nun.
Anzumerken ist nur noch, dass diese Version der „Datenübernahme“ nur für Spezialfälle gewählt werden sollte. Ein Datenupdate, mit den von Microsoft bereitgestellten Tools, sollte vorgezogen werden.
Für Microsoft Dynamics AX 4.0 SP1 stehen auf den Microsoft Webseiten 2 PDF Dokumente zur Verfügen, welche die Hardwareanforungen an eine Systemumgebung mit 100 und 200 Benutzern beschreiben.
http://www.microsoft.com/dynamics/ax/product/hardwaresizing.mspx
Man sollte die dort getätigten Aussagen aber eher als eine Art "grundlegende Richtlinie" verstehen, da die realen Hardwareanforderungen eines einzelnen Dynamics AX System, bedingt durch die spezifischen Anpassungen, in einzelnen Punkten variieren können.
Ab der Version 4.0 von Dynamics AX ist es möglich, an einem AOS, die Neuanmeldung von Benutzern zu sperren.
Um Benutzern die Anmeldung an einem AOS zu untersagen muss der entsprechende AOS auf dem Reiter „Serverinstanzen“ der Maske „Onlinebenutzer“ angewählt werden und der Button „Neue Clients ablehnen“ betätigt werden.
Hierbei wird der AOS in den Status „Belastung“ geschaltet.
Ab diesem Zeitpunkt akzeptiert dieser AOS keine Neuanmeldungen mehr.
Mit dem Button „Neue Clients akzeptieren“ kann dies Rückgängig gemacht werden.
Der AOS wird in den Status „Aktiv“ gesetzt.
Allerdings bringt das Untersagen von Neuanmeldungen in einer Dynamics AX Umgebung mit nur einem AOS auch einige Gefahren mit sich.
Wird der Client bzw. die Benutzersitzung des Benutzers mit administrativer Berechtigung geschlossen, und hat dieser keine weiteren aktiven Sitzungen mit ebenfalls administrativen Berechtigungen geöffnet, so hat sich der Administrator selbst vom System ausgesperrt.
Die Sperrung von Neuanmeldungen kann nun nicht mehr rückgängig gemacht werden.
Es ist dann nur noch möglich, den AOS neu zu starten um sich wieder anmelden zu können, da bei einem Neustart eines AOS dessen Status automatisch wieder auf „Aktiv“ gesetzt wird.
Möchte man nach einem Upgrade von Microsoft Dynamics AX 4.0 auf Microsoft Dynamics AX 4.01 einen neuen Benutzer anlegen erhält man die Fehlermeldung "".
Dies läßt erst einmal auf ein Problem im Quellcode von Microsoft Dynamics AX schließen.
Grund für die Fehlermeldung ist aber kein Fehler im Quellcode, sondern ein fehlerhafter Datensatz in der Tabelle "SysPerimeterNetworkParms". In diesem Datensatz steht im Feld "PNType" ein ungültiger Wert.
Wird dieser Wert auf einen gültigen Wert (None) geändert, können auch wieder neue Benutzer im System angelegt werden.
Folgender Job kann zur Behebung des Problems verwendet werden:
(Verwendung auf eigene Gefahr. Es wird keine Garantie oder Haftung für die Funktion und Richtigkeit des Quellcodes gegeben. )
static void CorrectAxaptaUserImportError(Args _args)
{
SysPerimeterNetworkParams p;
DataArea a;
;
while select a
{
changecompany(a.Id)
{
p = null;
ttsbegin;
while select forupdate p
{
p.PNType = PerimeterNetworkType::None;
p.update();
}
ttscommit;
}
}
}
Im Microsoft PartnerSource ist ein Dokument erhältlich, welchen den Updateprozess beschreibt, der durchzuführen ist, wenn man ein Update von Microsoft Dynamics AX 4.0 auf Microsoft Dynamics AX 4.01 durchführen möchte. Alles in allem ist dieses Dokument eine sehr gute Informationsquelle, die fast alle Einzelheiten, die bei dem Update zu beachten sind, erläutert. Bedauerlich ist nur, dass eine sehr wichtige "Kleinigkeit" nicht in diesem Dokument erwähnt wird. Hält man sich strickt an die Dokumentation, so wird man leider feststellen, dass sich der AOS nach der Installation von Microsoft Dynamics AX 4.01 nicht mehr starten lässt. Es wird zwar ein Eintrag im EventLog erzeugt, dieser ist aber nicht besondern hilfreich (Error 110). Grund für diese Fehlermeldung sind die beiden StoredProzedures die ab Microsoft Dynamics AX Version 4.0 in jeder Microsoft Dynamics AX Datenbank vorhanden sein müssen. Da die Datenbank an sich nicht "geupdatet" wird, werden diese SP`s ebenfalls nicht geändert und bleiben damit auf dem Stand von Microsoft Dynamics AX 4.0. Und leider scheint Microsoft Dynamics AX 4.01 genau mit diesen SP`s nicht zusammen arbeiten zu können. Die Lösung des Problems gestaltet sich zum Glück recht einfach: Die SP's müssen einfach nur gegen die beiden SP's einer Microsoft Dynamics AX 4.01 Datenbank ausgetauscht werden und schon funktioniert der AOS wie erwartet.
Ein weiteres Problem beim Update auf die neue Version Microsoft Dynamics AX 4.0 kann der Name des Unternehmenskontos sein. Wird ein Unternehmenskonto verwendet, dass in seinem Namen ein „&“ enthält, z.B. „A&B“, werden einige Prozesse beim „Datenaktualisierung nachsynchronisieren“ mit einem Fehler abgebrochen. Im Ereignislog ist dann ein Eintrag des Dynamics AX 4.0 Servers zu finden, der wie folgt lautet (Ausschnitt): „…[Microsoft][ODBC SQL Server Driver][SQL Server]Falsche Syntax in der Nähe von '&'.. The SQL statement was…“ Daraus wird ersichtlich, das dass „&“ Zeichen als SQL Statement erkannt wird und die SQL Anweisung so fehlerhaft interpretiert wird. Dieses Problem kann nur gelöst werden, indem man in dem zu updatenden Microsoft Dynamics AX 3.0 ein neues Unternehmenskonto erstellt das kein „&“ Zeichen beinhaltet (Am einfachsten geht dies mit der Dublizierfunktion der Unternehmenskonten).
Für die Planung und Durchführung eines Updates stehen folgende Informationsquellen zur Verfügung:
- Microsoft Dynamics AX Upgrade Tools Guide (PDF Dokument, Erhältlich im PartnerSource)
- Microsoft Dynamics AX 4.0 Implementation Guide (CHM File, Dynamics AX 4.0 Dokumentation)
- Inside Microsoft Dynamics AX 4.0 (Buch, Microsoft Press)
Diese enthalten eine gute Beschreibung der einzelnen Schritte die erforderlich sind, um von der Version 3.0 auf die Version 4.0 von Microsoft Dynamics AX zu updaten.
Allerdings können noch einige Probleme bei dem Updateprozess entstehen, die leider nicht Besprochen werden und für die auch in den bekannten Newsgroup, Blogs und Communitys noch keine Lösungsvorschläge gibt.
So sollte ein Upgrade immer in dem Layer durchgeführt werden, in dem die Anpassungen durchgeführt wurden (z.B. CUS oder VAR). Dies hat zur Folge das man u.U. die Anwendung mehrfach kompilieren muss, da man erst nach dem einlesen der Lizenzdatei zugriff auf diese Layer erhält.
Weiterhin kann man beim Durchführen der Synchronisierung folgenden Fehler erhalten:
"Cannot execute a data definition language command on (). The SQL database has issued an error."
Ursache hierfür kann sein, dass der ConfigurationKey "CSESpain" ist in dem Microsoft Dynamics AX 3.0 System, welches geupdatet werden soll, nicht angeschaltet ist/war.
Dadurch sind drei Felder ("Action", "CustVendParameter", "CustVendAccount") der Tabelle "SalesPurchaseCycle" deaktiviert, die allerdings den eindeutigen Index "SalesPurchaseCycle" bilden. Dadurch werden Datensätze in die Tabelle geschrieben, die nicht dem eindeutigen Index entsprechen. Beim Update auf Microsoft Dynamics AX 4.0 wird dieser Index überprüft bzw. neu geschrieben und das Synchronisieren wird mit einem Fehler abgebrochen, da die Datensätze der Tabelle nicht eindeutig sind.
Das Problem kann gelöst werden, indem man auf der Tabelle "SalesPurchaseCycle" den eindeutigen Index "SalesPurchaseCycleIdx" auf "Enabled = NO" setzt.
Anschließend sollten alle Datensätze in dieser Tabelle in allen Unternehmen gelöscht werden und der Index "SalesPurchaseCycleIdx" wieder auf "Enabled = YES" gesetzt werden.
Die Deaktivierung des ConfigurationKey "CSESpain" reicht leider nicht aus, da es dann zu Problemen beim "Datenaktualiserung nachsynchronisieren" kommen kann, da dort die einzelnen Datensätze überprüft werden (5 Prozesse werden deswegen mit einem Fehler beendet).
Weiterhin sei noch angemerkt, dass alle Anpassungen in Bereich der "Forms" zu erheblichen Problemen beim Codeupgrade führen können.
Viele Formelemente wurden in der neuen Version 4.0 unbenannt, was dazu führen kann, dass eine einzige Anpassung (z.B. Änderung nur einer Formproperty) mehrere hundert Fehler erzeugen kann.
Bsp.: Änderung einer Property der Form "CompanyInfo" im upzudatenden Microsoft Dynamics AX 3.0 System führte zu 126 Fehlern im Microsoft Dynamics AX 4.0 System.
Deswegen sollte man vor einem Update genauestens überlegen/überprüfen, ob es überhaupt Sinn macht die getätigten Anpassungen mit zur neuen Version (4.0) zu migrieren.
Oft können getätigte Anpassungen durch Erweiterungen im Standard abgelöst werden, die eine ähnliche Funktionalität bieten. In machen Fällen ist es unter Berücksichtigung der benötigten Zeit sogar Sinnvoller, die Anpassung erneut im Microsoft Dynamics AX 4.0 System vorzunehmen.
Eine Migration der Anpassungen sollte nur in Erwägung gezogen werden, wenn keine andere Lösung gefunden werden kann.
Wer auf der Suche nach Dokumentation zu / über Dynamics Ax 4.0 ist, sollte mal einen Blick auf diese Seite werfen:
Using Microsoft Dynamics AX
Um den Text, der in der Titelleiste des Dynamics AX Clients angezeigt wird, zu ändern muss man folgendes machen:
- Auf dem Clientrechner in das Axapta Client Installationsverzeichnis wechseln.
- Im Unterverzeichnis "Client\Bin" die Datei "Axsys$$.KTD" mit einem Texteditor öffnen.
($$ steht hierbei für das entsprechde Länderkürzel. Z.B. de)
- Das Label "#1076" wie gewünscht anpassen.
Nach einem (Neu)Start des Dynamics AX Clients wird nun der in dem Label eingetragene Text in der Titelleiste des Dynamics AX Clients angezeigt.
Um auf einen Dynamics Ax Object Server, der durch eine Firewall gesichert ist, zugreifen zu können müssen in der Firewall folgende Regeln vorhanden sein.
1. Allow all incoming TCP traffic on AOS Port to AOS IP.
2. Allow all outgoing TCP traffic.
3. Allow all incoming UDP traffic on Port 2712 to AOS IP.*
4. Allow all outgoing UDP traffic.*
Weiterhin muss die Firewall UDP NAT unterstützen.*
Möchte man weiterhin noch eine lokale Firewall auf den jeweiligen Clients betrieben sollte diese wie folgt Konfiguriert sein.
1. Allow all outgoing TCP traffic on AOS Port to AOS IP.
2. Allow all incoming TCP traffic for Dynamics Ax Client (ax32.exe).
3. Allow all outgoing UDP traffic on Port 2712 to AOS IP.*
4. Allow all incoming UDP traffic for Dynamics AX Client (ax32.exe).*
* Sollte die verwendete Firewall kein UDP NAT untestützen bzw. sollten die entsprechenden UDP Regeln nicht eingepflegt werden können, besteht noch die Möglichkeit, dass man dem Dynamics Ax Client mittels -aos=host:port direkt einem AOS zuweißt.
Damit versendet der Dynamics AX Client keine Broadcast mehr über UDP, um die im Netz befindlichen Dynamics AX Object Server zu ermitteln, sondern Verbindet sich direkt mit dem über "host:port" angegebenen AOS. Allerdings gibt es hierbei die Einschränkung, dass keine AOS Cluster verwendet werden können, da der Client sich immer auf den angegebenen AOS verbindet.
Dynamics Ax erlaubt das mehrmalige Anmelden unter einer Benutzerkennung.
So kann ein Benutzer eine beliebige Anzahl an Sitzungen mit seiner Benutzerkennung öffnen.
Möchte man aber die mögliche Anzahl an Sitzungen unter einer Benutzerkennung begrenzen, ist dafür
eine Anpassung der Info Klasse notwendig.
Fred Shen beschreibt in seinem Blog, wie diese Anpassung auszusehen hat.
|