NilsK

Moin,

nein, so geht das leider nicht. Du kannst nicht den ganzen Profilordner kopieren, das wird fehlschlagen. Du musst dich auf die jeweiligen Dokumente beschränken (bzw. Ordner, in denen nur Dokumente liegen) und komplexere Programme wie Outlook per Export/Import übertragen.

Gruß, Nils

Moin,

NewSid oder Sysprep hat mit dem hier diskutierten Profilproblem genau gar nichts zu tun. Darüber hinaus ist NewSid nicht supportet und dafür bekannt, dass es Probleme verursacht (weswegen der Hersteller es auch zurückgezogen hat, wenn auch leider mit Jahren Verspätung).

Gruß, Nils

Moin,

wenn du alles quasi "eins zu eins" übernehmen willst, benötigst du eine Lösung wie SecureCopy von ScriptLogic.

Es könnte aber ein günstigerer und evtl. sinnvollerer Weg sein, die lokalen Berechtigungen durch Berechtigungen für AD-Gruppen (Domänenlokale Gruppen) zu ersetzen. Dabei können dir Werkzeuge wie SubInAcl, SidWalk oder andere helfen.

Gruß, Nils

Moin,

ja, das ist richtig dargestellt. Wobei, wie gesagt, SQL Server sowieso nur über T-SQL kommuniziert, das allein ist also nicht der Punkt. Die Anwendungslogik muss so aufgebaut sein, dass die definierten Transaktionen auch tatsächlich einen konsistenten Stand ergeben - wie Lukas korrekt betont.

Gruß, Nils

Moin,

Welche Vorkehrungen müsste ich treffen um den Datenverlust im Falle eines Failovers gegen 0 zufahren? Wenn ich das so wie in den ersten Beiträgen geschrieben habe nur Clustern würde, dann wären die Informationen aus dem Arbeitsspeicher des Aktiven Notes ja verloren.

wie schon geschrieben: Datenverlust aus dem nicht versorgten RAM kann nicht auftreten, wenn es um einen Serverfehler geht. Genau dafür ist ja das Transaktionsprotokoll da. Nur wenn der Server und das Log-Volume gleichzeitig kaputtgingen, träte Datenverlust auf. Um dieses Risiko zu mindern, setzt man auf ein entsprechend abgesichertes Storage-System.

Mit T-SQL müssten dann unsere Entwickler arbeiten. Die Anwendung die wir mit dem SQL Server nutzen wollen wird selbst programmiert.

Dann sollten sich eure Entwickler rechtzeitig und ausführlich genug damit beschäftigen, denn erfahrungsgemäß ist sehr oft die Applikation verantwortlich für Probleme.

Gruß, Nils

Moin,

Wobei man hierzu noch sagen muss das mit Autocommit in einer falsch programmierten Applikation die Datenbank nachher logisch (d.h. auf Applikations-Ebene, nicht auf SQL-Server Ebene) korrupt sein kann, bzw. Geschäftsprozesse nur halb gelaufen sind aber als "komplett" markiert sind.

Bei einem teuren Unterbau mit aufwendiger Architektur sollte man auch die Applikation(en) genau beleuchten.

völlig richtig. Das sind dann einige der Fälle, in denen ein Cluster überhaupt nichts bringt. Das liegt dann in der Hand des Applikationsentwicklers und ist keine Schwäche der Transaktionssteuerung des SQL Server.

Gruß, Nils

Moin,

in den allermeisten Umgebungen ist es technisch gesehen egal, welche Rollen der zu sichernde Server innehat.

Aspekte dazu aber:

• Es sollte heutzutage ohnehin jeder DC auch GC sein.
  
• In den meisten Umgebungen ist es weder nötig noch sinnvoll, die FSMO-Rollen zu verteilen. Wichtig ist in erster Linie, dass man weiß, wo die Rollen liegen.
  
• Nach einem ordentlichen Restore würde ein DC auch dann nicht eine FSMO-Rolle einfach so annehmen, wenn man das AD-Backup eines FSMO-Inhabers wieder eingespielt hat. Vom Prinzip her würde ich allerdings trotzdem tendenziell das Backup auf einem Nicht-FSMO erzeugen.
  
• Es ist sinnvoll, mehr als einen DC (pro Domäne) zu sichern.
  
• Ich würde je nach Betriebssystem die verfügbaren Methoden mischen und ein Gesamtkonzept für verschiedene Schadensszenarien aufbauen.
  

Siehe auch:

faq-o-matic.net Video-Tutorial: Active Directory Object Recovery

Gruß, Nils

Moin,

Performance in bestehenden TS-Farmen erreicht man vor allem durch den Umstieg von 32 Bit auf 64 Bit und den entsprechenden RAM-Ausbau.

Zudem würde ich bei einer Neuinstallation auch den Punkt Support nicht außer Acht lassen - 2008 R2 wird eine ganze Weile länger supportet als 2003.

Gruß, Nils

Moin,

dann wäre zu prüfen, wie das Typo3 die Namensauflösung macht. (Und beachten: Das ist Reverse Lookup.) Nur weil eine Applikation was Falsches anzeigt, heißt das ja noch lange nicht, dass außerhalb der Applikation ein Fehler besteht.

Gruß, Nils

Moin,

eine fertige Lösung für "alles" gibt es nicht, nein. Es gibt u.U. fertige Lösungen für das, was du willst, aber dafür musst du 1. definieren, was du genau willst und 2. im Zweifel selber mal suchen.

Und, wie schon gesagt: Ja, die MMC ist für alltägliche Basis-Administration gedacht, nicht für Allzweckdatenpflege.

Gruß, Nils

Moin,

das ist so auch nicht ganz richtig.

Den Arbeitsspeicher kannst du nicht synchronisieren. Das wäre bei einem System, das für Höchstleistung geeignet ist (wie SQL Server) auch kaum sinnvoll machbar.

Das Transaktionsproblem besteht aber nicht. Jede Transaktion, die an SQL Server gesendet wird, wird im Transaction Log protokolliert, bevor SQL Server sie ausführt. Nach einem Server-Ausfall werden alle abgeschlossenen Transaktionen, deren Daten noch nicht in der Datenbank stehen, in diese kopiert (Rollforward) und alle nicht abgeschlossenen Transaktionen gelöscht (Rollback). Da letztere aber auch gegenüber dem Client nicht bestätigt wurden, gibt es auf diese Weise keinen Datenverlust.* Erst nach diesem Vorgang geht die Datenbank online. (Das ist auch der Grund für einen evtl- längeren Failover-Vorgang; zu kontrollieren im Eventlog.)

Mit T-SQL (als Sprache) hat das recht wenig zu tun. Applikationen können sich nicht an der Transaktionssteuerung vorbeimogeln, egal ob sie T-SQL sprechen (was fast alle tun) oder per .NET mit dem Server kommunizieren (was in den meisten Fällen auch auf eine T-SQL-Ansprache hinausläuft).

* Es sei denn, der Ausfall betrifft auch das Storage-System und beschädigt geschriebene Daten. (Das ist einer der Fälle, die Lian meinte.)

Ein paar Hintergründe findest du hier:

http://www.faq-o-matic.net/2009/03/20/warum-muss-eine-datenbank-zum-backup-konsistent-sein/

Und noch einmal die eindringliche Warnung: Die Fragen, die du stellst, sind nachvollziehbar und okay, aber sie deuten darauf hin, dass ihr bei dem Aufbau eines Hochverfügbarkeitssystems für SQL Server Unterstützung braucht. Klärt eure Anforderungen auf der geschäftlichen Ebene, bevor ihr Systementscheidungen trefft!

Gruß, Nils

Moin,

das stimmt so nicht. Du kannst dem DirectAccess-Client einen Server angeben, den er erreichen soll (sog. "Network Location Server") - keine Domain.

... du willst wirklich wegen Hörensagen deine Domain umbenennen?! Und wenn dir morgen jemand sagt, man solle sein Adminkennwort auf einer öffentlichen Webseite ablegen?

Gruß, Nils

Moin,

FTP ist jetzt aber nicht eben ein sicheres Protokoll. Wenn ich dein Kunde wäre, würde ich verlangen, dass du das absicherst. (Nur mal so am Rande.)

Gruß, Nils

... und als Ergänzung dazu: Kopieren musst du dann hinterher natürlich nur die Nutzerdaten (also Dokumente). Programme werden i.d.R. nicht nutzerspezifisch installiert.

Gruß, Nils

Moin,

der Grund, warum Microsoft sowas nicht supportet, liegt an umfangreichen schlechten Erfahrungen im Produktionsumfeld. Leider funktionieren Profile, die auf diese Weise erzeugt wurden, nämlich bisweilen nicht dauerhaft, d.h. irgendwann wird das Profil nicht mehr geladen. Das resultiert im günstigen Fall mit der Anmeldung mit einem temporären Profil, im ungünstigen schlägt die ganze Anmeldung fehl. Ärgerlich, wenn in dem Profil jetzt wichtige Daten lagen - der EFS-Key beispielsweise ...

Solche Probleme treten auch mit "normalen" Profilen manchmal auf, mit "geklonten" aber eben leider deutlich häufiger.

Gruß, Nils

Moin,

bis einschließlich Exchange 2007 macht Exchange Single-Instancing. Das bedeutet, dass z.B. Attachments erst dann aus der Datenbank entfernt werden, wenn kein Verweis mehr darauf besteht, d.h. wenn dasselbe Attachment bei allen Usern entfernt wurde, die es hatten.

Archivierung in PST ist i.d.R. keine gute Idee. Eine professionelle Mail-Archivierung wäre besser.

Gruß, Nils

Moin,

wo (auf welcher Ebene) wurde die Kontensperrung definiert? In einem eigenen GPO? Wie wurde das zurückgenommen - GPO entfernt? Werte ausdrücklich neu gesetzt?

Und wie kommt man auf die Idee, in einer Domäne leere Kennwörter zuzulassen?

Gruß, Nils

Moin,

evtl. ist auch das Database Mirroring interessant für euch. Potenziell kommt es ohne SAN aus und erlaub kürzere Umschaltzeiten als ein Cluster. Allerdings sind einige Bedingungen in der Umgebung nötig und einige Einschränkungen zu beachten.

Deine zuletzt genannten Überlegungen treffen zu, allerdings wäre in einem Aktiv/Aktiv-Szenario neben der Last im Failover-Fall einiges zu beachten. Daher rät man im Allgemeinen eher davon ab.

Wichtig ist, dass ihr genau eure Anforderungen definiert und erst danach eine Lösung entwerft, ggf. mit einem erfahrenen Berater. Zu den Anforderungen gehören tolerierbare Ausfallzeit/Wiederanlaufzeit, tolerierbarer Datenverlust, tolerierbare Einschränkungen im Notbetrieb (z.B. längere Antwortzeiten, nicht alle Arbeitsplätze voll arbeitsfähig usw.), Budget.

Wichtig ist ebenfalls die Frage, gegen welche Schäden ihr euch denn absichern wollt, denn ein Cluster hilft euch nur bei einer kleinen Teilmenge typischer Schadensfälle. Ihr braucht also auch ein passendes Recovery-Konzept. Und die technisch-organisatorische Umgebung muss stimmen (z.B. ausreichende Redundanz in angrenzenden Bereichen, Notfallkonzepte, Wiederanlaufplan).

Gruß, Nils

Moin,

taucht der Ordner in folgender Anzeige auf?

csvde -f PublicFolders.txt -r "(objectClass=publicFolder)" -l name

Wenn du per OWA auf den Exchange zugreifst und dort das Adressbuch nutzt, wird der Ordner dort angezeigt? Falls nein, kann es sein, dass das Outlook, das du nutzt, Synchronisationsprobleme hat und schon lange keine neue Offline-Adressliste mehr heruntergeladen hat?

Du kannst auch mal ADSI Edit öffnen (adsiedit.msc) und dich mit dem Default Naming Context verbinden. Wenn du dann den Knoten "CN=Microsoft Exchange Objects" öffnest, siehst du dort bei den Public Folders deinen Ordner?

Gruß, Nils

Moin,

richte doch einfach eine Freigabe ein und einen lokalen User auf dem Server, der zum Zugriff berechtigt ist.

Gruß, Nils

Moin,

ich kann da nur mutmaßen. Man könnte versuchen, ob es mit Aliasnamen und dem Abschalten des Strict Name Checking geht. Ist aber jetzt rein hypothetisch.

faq-o-matic.net Servermigration mit Netbios-Aliases

Gruß, Nils

Moin,

die Freigaben liegen auf dem iSCSI-Laufwerk? Dann steht dessen Treiber zu spät zur Verfügung, nämlich erst nachdem Windows die Freigaben setzen will.

File shares on iSCSI devices may not be re-created when you restart the computer

Gruß, Nils

Moin,

dabei sind zwei Dinge zu unterscheiden: Die Umstellung des Mailflow und die Inhalte. Für Letzteres benötigst du ein Werkzeug, weil es keine Exportmöglichkeit aus Notes gibt, die Outlook lesen kann.

Problematisch dabei sind vor allem Kalendereinträge. Die machen immer mal wieder Probleme, weil die Formate zwischen verschiedenen Systemen so unterschiedlich sind.

Näheres:

MSXFAQ.DE - Migration und Koexistenz

MSXFAQ.DE - TransporterSuite

Gruß, Nils

Moin,

die Bezeichnung "Enterprise" ist durchaus ernst gemeint. Sie bezeichnet die Anforderungen großer Unternehmen.

80 Mailboxen wirst du in einer Datenbank unterbringen. (Selbst das Zehnfache wäre dabei möglich.) In so einem Szenario wird man kaum mehrere Datenbanken nutzen.

Selbst für einen einfachen Cluster in dieser Größenordnung bräuchtest du kein Exchange Enterprise, weil die DAG auch mit der Standard Edition möglich sind. (Nur das OS müsste dann Enterprise sein.)

Gruß, Nils

Moin,

ein einfacher Test dauert ca. 30 Sekunden ...

Gruß, Nils