Exchange 2013 Datenbank inkonsistent - wie "manuell" sichern und Konsistenz prüfen/reparieren?

[Blase 15]

So, ich mache bis hier hin und warte mal euer Feedback ab.

 

Ich habe die Umlaufprotokollierung aktiviert. Das Resultat war, dass quasi alle LOG Dateien, bis auf die aktuellsten, verschwunden waren. "Super" - dachte ich und gleich mal die Sicherung gemacht. Die bricht aber trotzdem mit der Meldung ab (von "alt" nach "neu" - nur die "Fehler" und "Warnungen")

 

1)

 

Fehler beim Kryptografiedienst während der Verarbeitung des "OnIdentity()"-Aufrufobjekts "System Writer".

Details:
TraverseDir : Unable to push subdirectory.

System Error:
Unbekannter Fehler

 

2)

 

Fehler bei der Microsoft Exchange VSS Writer-Sicherung. Es wurden keine Protokolldateien abgeschnitten. Instanz '4f359206-52b5-4f40-8967-22022c95eec3'. Datenbank '70bb4234-fddf-49d1-80e8-bcc69fc253c3'.

 

3)

 

Microsoft Exchange-Replikationsdienst: Fehler von VSS Writer (Instanz 4f359206-52b5-4f40-8967-22022c95eec3) mit Fehler FFFFFFFC bei der Verarbeitung des Sicherungsabschlussereignisses.

 

4)

 

Behebbarer Fehler des Writers "Microsoft Exchange Writer" beim Erstellen der Schattenkopie. Der Vorgang wird wiederholt...  Weitere Informationen: "".

 

5)

 

eseutil (20052) JetDBUtilities - 20072: Fehler nach 0.000 Sekunden beim Lesen aus Datei "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 2137044815\E0000002005.log" bei Offset 4096 (0x0000000000001000) für 262144 (0x00040000) Bytes mit Systemfehler 21 (0x00000015): "Das Gerät ist nicht bereit. ". Fehler -1022 (0xfffffc02) bei Leseoperation. Wenn dieser Zustand andauert, ist die Datei möglicherweise beschädigt und muss aus einer vorherigen Sicherung wiederhergestellt werden.

 

6)

 

eseutil (20052) JetDBUtilities - 20072: Fehler nach 0.000 Sekunden beim Lesen aus Datei "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 2137044815\E0000002005.log" bei Offset 4096 (0x0000000000001000) für 4096 (0x00001000) Bytes mit Systemfehler 21 (0x00000015): "Das Gerät ist nicht bereit. ". Fehler -1022 (0xfffffc02) bei Leseoperation. Wenn dieser Zustand andauert, ist die Datei möglicherweise beschädigt und muss aus einer vorherigen Sicherung wiederhergestellt werden.

 

7)

 

eseutil (20052) JetDBUtilities - 20072: Fehler nach 0.000 Sekunden beim Lesen aus Datei "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 2137044815\E0000002005.log" bei Offset 8192 (0x0000000000002000) für 4096 (0x00001000) Bytes mit Systemfehler 21 (0x00000015): "Das Gerät ist nicht bereit. ". Fehler -1022 (0xfffffc02) bei Leseoperation. Wenn dieser Zustand andauert, ist die Datei möglicherweise beschädigt und muss aus einer vorherigen Sicherung wiederhergestellt werden.

 

8)

 

eseutil (20052) JetDBUtilities - 20072: Die Protokolldatei \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 2137044815\E0000002005.log ist fehlerhaft, ungültig oder der Zugriff darauf kann nicht erfolgen (Fehler -1022). Sie kann nicht verwendet werden. Wenn diese Protokolldatei für die Wiederherstellung erforderlich ist, wird eine einwandfreie Kopie benötigt, damit die Wiederherstellung erfolgreich abgeschlossen werden kann.

 

Die angesprochene "E0000002005.log" gibt es in dem Verzeichnis aber nicht - geht dort erst mit der "E0000002006.log" los. Davon ausgehend, dass ohnehin dort im Verzeichnis die ganzen LOG Dateien raus sind, wollte ich erst einmal eure Meinung hören. Trotzdem dann mit dem ursprünglichen Plan weiter machen? Bereitstellung aufheben, Dienst beenden, "Reste" aus dem Verzeichnis rauslöschen und anschließend Sicherung noch einmal versuchen? Würde ich dann morgen Abend machen....

 

Gute Nacht!

 

Björn

[RobertWi 81]

Moin,

 

so wie es scheint, hat sich wirklich irgendwo der Zähler für das Backup vertan.

 

Du kannst das nun so probieren, wie hier im Forum beschrieben (Löschen oder neue DB und umziehen).

 

Da die Datenbank eh von C wegsollte und am besten auf eine eigene Festplatte, ist ein Umzug eventuell doch der schönere und sicher Weg. Neue Platte rein, neue Datenbank rauf, Postfächer umziehen.

 

Das geht dann alles ohne Ausfall und nur mit einer kurzen Störung für die Anwender.

 

Unabhängig davon solltest Du unbedingt die Festplatte überprüfen um Hardwarefehler auszuschließen.

[Blase 15]

Moin Robert,

 

was sind denn die Gründe die für eine Auslagerung der Datenbank auf eine eigene Partition (oder gar HDD) sprechen? Diese Info kommt wohl für diesen Kunden zu spät (realistisch werden wir das hier sicherlich nicht mehr umsetzen), aber für zukünftige Projekte will ich das gerne berücksichtigen.

 

Also mal einen kompletten checkdisk über die Platte laufen lassen? Bin grade am Überlegen, ob ich dafür zwingend davor sitzen muss, oder ob ich das "Remote" auch hinbekomme. Also ob er Eingabeaufforderungen von mir haben möchte oder nicht. Ich hoffe nicht, grade auch weil das ziemlich lange dauern wird und ich das lieber remote über Nacht laufen lassen wollte.

 

Und anschließend, wenn die Platten i.O. sind, dann weiter mit dem ursprünglichen Plan...

 

Gruß

Björn

[RobertWi 81]

was sind denn die Gründe die für eine Auslagerung der Datenbank auf eine eigene Partition (oder gar HDD) sprechen?

 

Das ist eigentlich vollkommen unabhängig von Exchange. Es gilt grundsätzlich die Regel, dass man Daten von Programmen trennt.

 

Gründe:

- Fragmentierung

- Performance

- saubere Datentrennung -> wichtig bei Festplattenausfällen, denn ist entweder Exchange noch da oder die Daten, aber nicht beides weg

- andere Backup-Strategie möglihch

- andere RAID-Systeme möglich

- läuft aus irgendeinem Grund die Exchange-Partition voll (passiert gerne mal per Viren-/Spam-Angriffen und Programmfehler gab es auch schon), ist bei Dir auch C voll -> mag Windows gar nicht

- ist die Datenpartition voll, brauchst Du bei Trennung nur eine neue Platte; hier musst Du eventuell neuinstallieren, fehleranfällig klonen oder sonst irgendwie basteln

 

 

Also mal einen kompletten checkdisk über die Platte laufen lassen?

 

 

checkdsk, Eventlogs, smart, Herstellertools - alles was es da so gibt.

 

Bin grade am Überlegen, ob ich dafür zwingend davor sitzen muss, oder ob ich das "Remote" auch hinbekomme.

 

Da das C ist, bekommst Du checkdisk Reparaturen nur mit Reboot hin, weil die Systempartition im laufenden Betrieb nicht ausgehängt werden kann (addiere "bessere Reparaturoptionen" zu meiner obigen Liste).

[Dukel 454]

Wenn nur neben dem entfernen der Datenbank von C: noch die Transaktionsprotokolle von der Datenbank trennst (eigene Platten) kannst du z.B. bei einem Ausfall der Datenbank kannst du mit Hilfe eines Backups und der noch vorhandenen Protokolle ohne Datenverlust das System wieder herstellen. Wenn alles auf einer Platte liegt (und diese Ausfällt) kannst du das nicht ohne Datenverlust (je nach Backupzeiten).

[Blase 15]

 (addiere "bessere Reparaturoptionen" zu meiner obigen Liste).

 

Touché ;-)

 

Nein, dass ich dafür einen Reboot brauche, ist klar. Es ist nur die Frage, ob der dann alles weitere komplett selbständig durchführt, bis ich dann wieder die Kontrolle unter Windows habe und mich remote drauf schalten kann.

 

Ok, dachte vielleicht gibt es einen speziellen "Exchange-Grund" das zu trennen. Bis auf den anderen RAID-Level wäre also eine zweite Partition dahingehend auch hinreichend, ja? Muss also nicht gleich ne andere/weitere Platte sein.

 

@Dukel - Wenn meine letzte Sicherung also von gestern ist und heute mir die Datenbank "flöten" geht, ich aber alle aktuellen Protokolle beisammen habe, kann ich damit den aktuellen Stand wieder herstellen, ja? Ok, habe ich verstanden.

[RobertWi 81]

:)

 

Wie Dukel schon schreibt, kann eine weitere Trennung Log und DB sinnvoll sein. "Kann", weil man hier keine Pauschalaussage treffen kann. In Single-Installation wäre die Trennung sinnvoll. Bei DAG braucht man sie nicht mehr. Und wer es ganz auf die Spitze treibt, benutzt noch unterschiedliche RAID-Systeme.

 

Zu 2003er Zeiten konnte das dann so aussehen:

 - C -> RAID 1

 - DB -> RAID 5

 - LOG -> RAID 10

 

Das macht dann mal locker 9 Platten - für eine DB! Bei der zweiten DB sollte das RAID 5 noch mal kommen (Logs waren damals noch pro Speichergruppe, d.h. zwei DB teilten sich die gleichen Logs).

 

Eine Trennung aus Performance-Gründen ist aber seit 2010 nicht mehr notwendig und auch nicht grundsätzlich empfohlen. Eine Trennung aus Sicherungsgründen ist es aber schon. Und ein paar andere Argumente, wenigsten zwei Platten zu nutzen, findest Du oben.

 

Und den für mich wichtigsten Grund habe ich noch gar niht gesagt: Es sieht einfach ordentlicher aus. :)

Sizing und Storage für Exchange ist eine Wissenschaft für sich. ;)

[Blase 15]

*Puh* 9 Platten, anno 2003 dann am Besten auch noch SCSI oder wenigstens SAS (heute) Platten.... damit das "ordentlich aussieht", ist das eine ganze Stange Geld ;)

Aber ich verstehe natürlich den Sinn dahinter. Ich werde das zukünftig mehr berücksichtigen, als ich es bisher tat. Danke dir für die Erklärungen.

 

Dann bin ich ja mal gespannt auf heute Abend - so ich denn dazu komme - wird ja mal Zeit, dass das System endlich eine Sicherung bekommt...

[Blase 15]

Ist schon ein wenig her, aber da ich erst "jetzt" tatsächlich damit weiter mache - hier nun der aktuelle Stand:

 

Ich hatte, nachdem ich die Bereitstellung der DB aufgehoben hatte und den Dienst beendete, alles aus dem Verzeichnis heraus gelöscht, so dass nur noch der Ordner und die Datenbank übrig waren. Ich konnte nach wie vor nicht sichern.

 

Dann habe ich eine neue Datenbank angelegt und sämtliche Postfächer verschoben. Inkl. der Postfächer, die ich nur über die Shell angezeigt/verschoben bekomme ("New-MoveRequest -Identity...."). Weil ich daraufhin meine ursprüngliche Datenbank löschen konnte (davor meckerte er immer, dass da noch was drin sei), gehe ich zumindest davon aus, dass das soweit richtig ist. Das Problem - ich kann immer noch keine Windows Sicherung fahren...?!

 

Im Ereignisprotokoll steht folgendes von alt nach neu (nur Warnungen und Fehler):

 

1.

Fehler beim Kryptografiedienst während der Verarbeitung des "OnIdentity()"-Aufrufobjekts "System Writer".

Details:
TraverseDir : Unable to push subdirectory.

System Error:
Unbekannter Fehler

 

2.

Fehler bei der Microsoft Exchange VSS Writer-Sicherung. Es wurden keine Protokolldateien abgeschnitten. Instanz '954303b3-e8b1-4d74-b0b2-b9a6dd1422fd'. Datenbank '23db4b01-1576-4d09-aa35-4ad5ed93f739'.

 

3.

Microsoft Exchange-Replikationsdienst: Fehler von VSS Writer (Instanz 954303b3-e8b1-4d74-b0b2-b9a6dd1422fd) mit Fehler FFFFFFFC bei der Verarbeitung des Sicherungsabschlussereignisses.

 

4.

Behebbarer Fehler des Writers "Microsoft Exchange Writer" beim Erstellen der Schattenkopie. Der Vorgang wird wiederholt...  Weitere Informationen: "".

 

5.

Fehler bei der um ‎2014‎-‎05‎-‎15T12:23:02.997747200Z gestarteten Sicherung. Fehlercode: "0x80780102" (Der Systemgenerator wurde in der Sicherung nicht gefunden.). Suchen Sie in den Ereignisdetails nach einer Lösung, und führen Sie die Sicherung erneut aus, nachdem das Problem behoben wurde.

 

6. etwas "später"

Der Postfachreplikationsdienst von Microsoft Exchange konnte Aufträge in einer Postfachdatenbank nicht verarbeiten.
Datenbank: Fehlende Datenbank (70bb4234-fddf-49d1-80e8-bcc69fc253c3)
Fehler: Die Datenbank '70bb4234-fddf-49d1-80e8-bcc69fc253c3' ist nicht vorhanden.

 

Tja, ein wenig was "getan", aber vom Ergebnis her nicht weiter...

 

Weitere Ideen?

 

MfG Björn

[Blase 15]

Hallo,
 
das Problem konnte durch ein "befreundetes" Systemhaus nun gelöst werden.
 
Schlussendlich brachte das hier die Lösung:

http://support.microsoft.com/kb/2807849/de
 
Unter C:\Windows\Microsoft.NET\ gab es wohl Ordnerstrukturen mit >1000 Unterstrukturen, was die Sicherung wohl nicht "mag". Der im KB enthaltene Fix hat das Problem scheinbar behoben - die Sicherung läuft grade "normal" durch.

 

Ich bin happy ;-)

 

Gruß

Björn
 

[RobertWi 81]

Warum hast Du ein Visual Studio auf dem Exchange installiert?

 

Merke: Auf einen produktiven Exchange gehört nichts anders drauf, außer Exchange und die Produkte, die man direkt für Exchange braucht: Backup, Virenscanner, Archiv, Transport - fertig.

[Blase 15]

Hallo Robert,

 

wie im ursprünglichen Eingangsthema erwähnt, ist das der einzige Server im Unternehmen und demzufolge auch für mehr zuständig, als eben nur Exchange.

Ein Visual Studio ist dort eigentlich nicht wirklich drauf - wenn ich in die Software schaue, finde ich nur ein "Visual Studio 2010 Preerequisites - Englisch" - ist das schon der "Schuldige"?! Ich habe hier einen SQL Server 2012 R2 drauf - kommen damit nicht diese Komponenten mit? ich habe das jedenfalls nicht bewusst installiert und sonstige "Visual Studio" Komponenten sind hier nicht.

 

Das mit dem "ein Exchange ist ein Exchange ist ein Exchange" (kenne ich nur vom Hyper-V Server sonst), ist das eher "Empfehlung" oder gibt es handfeste Gründe, die gegen eine sonstige Nutzung sprechen? Tatsächlich ist das nämlich nicht der einzige Kunde, der diese oder eine ähnliche Konstellation bei sich im Einsatz hat - und bisher hatten wir solche Probleme nicht. Aber ich bin natürlich sehr gerne bereit, hier meinen beschränkten Horizont zu erweitern ;-)

 

Gruß

Björn

[RobertWi 81]

Ich habe hier einen SQL Server 2012 R2 drauf - kommen damit nicht diese Komponenten mit?

 

Ja. Sie sind Bestandteil der SQL Server Data Tools und werden auch von anderen Komponenten von SQL benutzt, da SQL Visual Studio als Entwicklungswerkzeug verwendet.

 

Das mit dem "ein Exchange ist ein Exchange ist ein Exchange" (kenne ich nur vom Hyper-V Server sonst), ist das eher "Empfehlung" oder gibt es handfeste Gründe, die gegen eine sonstige Nutzung sprechen?

 

Natürlich gibt es Gründe: Der Hauptgrund ist, dass die Entwickler von Exchange einfach nicht erwarten und darauf eingehen, dass da noch andere Komponenten drauf sind. Exchange braucht sehr viel von Windows und im Netzwerk und erwartete, dass das einen genau definierten Zustand hat. Hat es den nicht, knallt es i.d.R.

 

Beispiel: IIS. Exchange nutzt den für OWA, EAS und auch für die Verwaltung. Und es erwartet bestimmte Einstellungen mit dem Wert X. Nun installiert irgendjemand eine andere IIS-Anwendung, die den Wert auf Y ändert. Das Ergebnis ist nicht, dass Exchange meckert. Das Ergebnis ist: Exchange funktioniert nicht mehr.

 

Oder nimmt die PowerShell und WinRM: Wird von Exchange intensiv genutzt und erwartet daher bestimmte Einstellungen. Liegen die nicht vor, knallt es.

 

Exchange erwartet bestimmte Versionen von WinrRM, PowerShell, .NET und sogar mit dem Internet Explorer gab es schon Probleme, als der aktualisiert wurde und plötzlich die EMC von Exchange nicht mehr funktioniert.

 

Und die Logik ist nun ganz einfach: Je mehr fremde Dinge Du auf einem Exchange, desto höher ist die Wahrscheinlichkeit, dass Du Dir mit irgendeiner Komponente den Exchange zerschiesst.

 

Ich habe in meiner Zeit eine Menge defekte Exchange-Installation erlebt und da war eine Regel gut zu erkennen: Ein Exchange, der nur Exchange ist und nah am Best Practise betrieben wird, macht keine Probleme. Probleme gab es bis auf wenig Ausnahmen nur dann, wenn irgendwas fremdes auf dem Exchange war.

 

und dann gibt es natürlich praktische Dinge: CPU-Nutzung, RAM-Auslastung, Festplatten-Verwendung - kannst Du alles nicht steuern, wenn zu viele Programme auf einem Server sind.

 

Exchange ist ein Datenbank-System, dass massiv vom RAM lebt. Und wenn zu wenig RAM, dann muss die Festplatte ran. SQL ist ein Datenbank-System, dass massiv vom RAM lebt. Und wenn zu wenig RAM, dann muss die Festplatte ran. Merkst Du was? Was meinst Du, wie lange wird ein echte SQL auf einem Exchange wirklich gut gehen?#

 

Na ja, eigentlich hast Du die Frage schon hier in diesem Thread beantwortet. Ohne den SQL hättest Du keine Backup-Probleme des Exchange gehabt.

 

QED.

bearbeitet 3. Juli 2014 von RobertWi

[Blase 15]

Hallo Robert,

 

hab vielen Dank für deine Ausführungen. So rein praktisch bewege ich mich hier im KMU Segment - dort steht also in der Regel kein Server "Fuhrpark", sondern eher ein einziger Server. Wäre also die empfohlene Vorgehensweise in diesem Fall, den Server als Hyper-V Host zu betreiben und mit zwei virtuellen Systemen zu versehen - einem DC und einem Exchange (wäre doch in der Windows Server 2012 Standard Lizenz enthalten, oder? Also die Nutzung zweier virtueller Maschinen)?! Wäre das "best practise"? Das erhöht ja den Konfigurationsaufwand schon recht beträchtlich. Wenn ich dann noch meine SQL Anwendung betreiben möchte - auf dem Host läuft ja sonst nix und der Exchange ist, wie gelernt, ebenfalls "raus". Dann auf dem DC auch die SQL Anwendungen? Bestimmt kommt jetzt auch ein "Neeee!" ;-) Und man muss ja nicht mal sonderlich "groß" werden und schon kommt ein Terminal Server ins Spiel...

... Worauf ich hinaus will, ist, dass es in der Regel den Kunden im KMU Segment recht schwer zu erklären ist, warum sie 5-stellige Beträge (die Kosten für 2 x Hardware, Lizenzen und die "Woche+" Einrichtungskosten für mich) für "Hardware" ausgeben sollen. Versteh mich richtig, dass das gut und richtig und grade auch im Sinne des Kunden ist, ist klar. Nur du wirst ja sicherlich auch schon öfter mal (kleinere) Kunden getroffen haben, deren Vorstellung von "IT" etwas... na sagen wir "überholt" ist :) Und tatsächlich "läuft" es ja auch "quick & dirty". So ziemlich genau die selbe Konstellation (SQL + Exchange) auf einer anderen Kundenmaschine haben wir mehrfach und bisher hatte keine Probleme bezüglich der Sicherung gemacht. Und von der Sicherung mal ab, läuft diese Kiste auch "normal". Es ist halt immer eine schmale Gradwanderung - in diesem Segment. Klar, wir haben auch größere Kunden. Dort ist das Verständnis für die Kosten vorhanden - hier wirst du stellenweise "schräg" angeschaut, wenn die Zahl unten zu "klein" ist... ;-)

So oder so, werde ich zukünftig verstärkt darauf achten, deine Anmerkungen bezüglich Exchange umzusetzen!

 

Nochmals vielen Dank!

 

Gruß

Björn

[RobertWi 81]

Ich kann Deine Probleme nachvollziehen. Aber ist Aufgabe von Leuten wie uns als "externe Berater" den Kunden klar zu machen, dass auch KMU IT nicht für umsonst bekommen und ein gewisses Maß an Technik auch ein gewisses Maß an Geld kostet. Exchange ist ein tolles Produkt, aber das hat nun mal Anforderungen. Wenn er die nicht erfüllen will oder kann, dann kann halt kein Exchange einsetzen.

 

Der GF kommt ja auch nicht auf Idee, einen LKW zu kaufen, wenn er niemanden hat, der ihn fahren kann. Und er weiß, dass er hier also weiteres Geld ausgeben muss. Es ist wichtig, dass man den Leuten klar macht, dass gute und stabile IT eben auch kostet.

 

hab vielen Dank für deine Ausführungen. So rein praktisch bewege ich mich hier im KMU Segment - dort steht also in der Regel kein Server "Fuhrpark", sondern eher ein einziger Server.

 

Und brauchen dann zwingend Exchange? Sie rechnen sich irgendwelche Vorteile davon aus, sind aber nicht bereit, in den Aufwand zu investieren. Dann wäre Office365 zum Beispiel auch eine Möglichkeit. "Wasch mich, aber mach mich nicht nass" funktioniert nirgendwo, auch nicht in der IT.

 

Wäre also die empfohlene Vorgehensweise in diesem Fall, den Server als Hyper-V Host zu betreiben und mit zwei virtuellen Systemen zu versehen - einem DC und einem Exchange (wäre doch in der Windows Server 2012 Standard Lizenz enthalten, oder?

 

Das wäre zum Beispiel eine Möglichkeit und erlaubt. Ermöglicht schon mal die sinnvolle Trennung von DC und Exchange. Dazu noch eine weitere VM mit SQL (braucht aber auch eine weitere Lizenz und eventuell einen größeren Server).

 

Da fehlt dann zwar noch HA und DR, aber es ist schon mal eine deutlich bessere Rollentrennung.

 

 

Also die Nutzung zweier virtueller Maschinen)?! Wäre das "best practise"? Das erhöht ja den Konfigurationsaufwand schon recht beträchtlich.

 

Das kann man nicht pauschal sagen, weil es von Produkt zu Produkt unterschiedlich ist DC und Exchange bringen zum Beispiel Verfügbarkeit mit. Für einen Fileserver und SQL könnte man Hyper-V-Replication nehmen. Man kann das aber auch auf ein SAN packen und Hyper-V clustern.

 

 

Wenn ich dann noch meine SQL Anwendung betreiben möchte - auf dem Host läuft ja sonst nix und der Exchange ist, wie gelernt, ebenfalls "raus". Dann auf dem DC auch die SQL Anwendungen?

 

Für einen DC gilt der Satz "ein DC ist ein DC ist ein DC" genauso. Dort sind auch manche Dinge nicht mal supported, z.B. ein Hyper-V.

 

Bestimmt kommt jetzt auch ein "Neeee!" ;-) Und man muss ja nicht mal sonderlich "groß" werden und schon kommt ein Terminal Server ins Spiel...

 

Definiere "groß". Alles, was ich aus Deinen Sätzen immer herauslese ist, dass die ANFORDERUNGEN groß sind, aber nicht die Möglichkeiten!

 

Ich hätte auch gerne einen Pheaton, mein Geld reicht aber leider nur für einen Golf.

 

... Worauf ich hinaus will, ist, dass es in der Regel den Kunden im KMU Segment recht schwer zu erklären ist, warum sie 5-stellige Beträge (die Kosten für 2 x Hardware, Lizenzen und die "Woche+" Einrichtungskosten für mich) für "Hardware" ausgeben sollen.

 

Wieso? Sie wollen doch eine bestimmte LEISTUNG haben. Wieso kann man dann nicht sagen, dass kostet xx.xxxx Euro?

 

Versteh mich richtig, dass das gut und richtig und grade auch im Sinne des Kunden ist, ist klar.

 

 

Ebene. Es ist ja auch in seinem Sinne, wenn alles sauber läuft und nicht ständig bei jedem Update was schiefgeht und immer wieder ein (teurer!) Berater ins Haus muss, der das repariert.

 

Merke: Auch in der IT gilt - wer billig kauft, kauft doppelt. (damit meine ich nicht, dass Du billig bist, sondern nur, dass Kunden oftmals nur auf den Preis schauen und im nachhinein böse überrascht werden).

 

Nur du wirst ja sicherlich auch schon öfter mal (kleinere) Kunden getroffen haben, deren Vorstellung von "IT" etwas... na sagen wir "überholt" ist :)

 

Richtig. Und sobald mir klar wird, dass da eine gewisse Beratungsresistenz vorliegt, habe ich mir die Freiheit erlaubt, dem Kunden die Wahl zu lassen, entweder meine Expertise anzuerkennen oder sich jemand anderen zu suchen. Und natürlich führt das öfter auch "zu jemand" anderen, aber damit kann ich gut leben.

 

Ich habe aber auch schon oft den anderen Fall erlebt, wo ich Exchange Installationen "aufgeräumt" habe, die der kleine IT-Laden um die Ecker (der neben Server auch Webseiten und PHP macht, Drucker verkauft und Xboxen aufstellt) verbockt hat.

 

 

Und tatsächlich "läuft" es ja auch "quick & dirty". So ziemlich genau die selbe Konstellation (SQL + Exchange) auf einer anderen Kundenmaschine haben wir mehrfach und bisher hatte keine Probleme bezüglich der Sicherung gemacht. Und von der Sicherung mal ab, läuft diese Kiste auch "normal". Es ist halt immer eine schmale Gradwanderung - in diesem Segment.

 

Schmale Gradwanderung - gut ausgedrücket! Also lege ich alles daran, den Grat zu verbreitern. Und nicht darin, nicht abzustürzen.

 

Anyway: Ist glaube, die Gedanken sind klar geworden. Ich bin auch realistisch und weiß, wie die Praxis aussieht und dass die "Theorie nur theoretisch bis zur ersten Praxiserfahrung" gilt. Aber ein den Willen, das zu verbessern, habe ich trotzdem noch.