macmewes

Wenn Du die Möglichkeit hast, dann stelle doch mal die Daten aus einem Backup _vor_ diesem Phänomen auf einem anderen Datenträger vollständig wieder her und vergleiche dann bitte mal dessen physikalische Größe. Ich bin mir jetzt nicht sicher, ob Du das schon gemacht hast. Vielleicht erlebst Du dann das nächste Phänomen ;-) und die Daten aus dem Backup haben die gleiche Größe wie sie _jetzt_ angezeigt wird. Ansonsten bin ich ebenfalls ratlos :-|

Habe ich flacsh gelernt oder ist das Verschieben des Schemamasters nicht im Verschieben der FSMO-Rollen inbegriffen?

Korrekt :-)

Eine Sondersituation hat es mir ermöglicht alle Seminare und Prüfungen in vier Monaten (so in ca.) abzuhandeln. Hintergrund: Mein ehemaliger Arbeitgeber hat im September 2005 eine Massenentlassung angekündigt, der ich dann auch zum 01.03.2006 zum Opfer fiel. Da es sich hierbei nicht um eine hamburgische, sondern eine Entscheidung des Mutterkonzerns in Italien handelte, konnte ich erfolgreich bei meinem Chef vorsprechen. Dieser hat mich dann bei vollen Bezügen bis zum Kündigungstermin freigestellt. In dieser Zeit habe ich dann alle Seminare und Prüfungen tagsüber in Vollzeit gemacht (alles selber finanziert). Um nun meine Karriere weiter zu forcieren werde ich den Zertifizierungsweg weiter beschreiten und erstmal den letzten Schritt zum MCT machen und später noch die 070-282 für den Small Business Server abarbeiten. Ab dem 01.04.2006 bin ich dann selbstständig, weil auch die Zertifizierung zum MCSE2003 Messaging irgendwie keine Türen öffnen konnte. Darf ich hier auch mal über meine Bewerbungen abko**en ? Bewerbungsgespräche hatte ich in dieser Zeit einige, aber interessiert war man nur an einer billigen Arbeitskraft und das, was man mir z.T. so für eine Vollzeitstelle angeboten hat, kann ich sicherlich auch ganz für mich alleine erwirtschaften. Mir kam es manchmal so vor, also wollte man nur den MCSE haben (um den Microsoft-Partner-Status von Silber auf Gold zu heben) aber nicht mich. Da kamen dann so Floskeln wie: "Wir wissen ja nicht wie wir Sie einschätzen sollen." Zugegeben: Ich habe zuletzt funf Jahre produktiv in einem Windows NT4 Umfeld gearbeitet, von daher fehlt mir die praktische Erfahrung mit Windows Server 2003. Was mich so mürbe gemacht hat, war das die Unternehmer Probleme damit hatten, Risiken einzugehen. So als ob es den Status "Probezeit mit Kündigung von Heute auf Morgen" nicht gibt (habe ich so angeboten). Ist auch egal: Es geht weiter und ich habe ein klares Ziel vor Augen :-D

Guckst Du hier: http://www.msexchangefaq.de/internet/default.htm

Wenn ich micht recht erinnere, dann möchte MS, daß Du ein normales Backup am Sonntag machst und von Montag-Samstag jeweils inkrementelle. Ansonsten stimme ich Dir zu: Wenn es zeitlich passt, dann kann eine tägliche Vollsicherung nicht schaden.

Ich habe heute morgen die letzte meiner Prüfungen bestanden und darf mich nun MCSE 2003: Messaging schimpfen :-D

Geht es hier um einen WSUS-Client oder um einen WindowsUpdate/MicrosoftUpdate-Client? Google bitte mal nach: "WindowsUpdateAgent20-x86.exe" und probiere dann ein "WindowsUpdateAgent20-x86.exe /wuforce /quiet /norestart" Dies sollte den WindowsUpdate-Agent wieder ins System prügeln. Hat bei mir immer funktioniert.

Allgemeine Daten haben auf einem DC eigentlich nichts verloren und ich halte die Wette mit dem Hintern und lege noch meinen A**** dazu, daß es am SMB-Signing liegt. Wenn also Daten auf den DC müssen, dann muß das SMB-Signing ausgeschaltet werden. Das SMB-Signing gilt (wie bereits richtig erkannt) nur für Domainen Controller und wenn es nicht ausgeschaltet werden darf, dann müssen die Daten vom DC runter. Zum Thema SMB-Signing kannst Dich auch direkt bei Apple informieren: http://www.apple.com/de/macosx/features/windows/ http://pdf.euro.apple.com/pdf/pn=WindowsTiger/MacOSX_Windows_TB.pdf Noch eine Sache: Windows Server 2003 hat per default keine Unterstützung mehr für NTLM (New Technology LAN Manager), welches mit NT4 eingeführt wurde. Es wird nur noch NTLM v2 per default unterstützt. Prüfe doch bitte mal, ob Du NTLM nachinstallieren kannst und ob dann was geht. Die Wette mit meinem A**** bzgl. SMB-Signing steht :-D

Die "Services for Unix" sind eher dazu gedacht, daß man Freigaben auf einem Windows Server von unixoiden Systemen per NFS einbinden kann (als Beispiel). Den anderen Weg habe ich noch gar nicht probiert ;-) Des weiteren, reden wir hier jetzt von Unix oder von Linux - nicht, daß Du hier was verwechselst. Ich habe keine Ahnung, ob die kommerziellen Unixe mittlerweile irgendwie NTFS drauf haben, aber mit Linux-Systemen geht das nicht "out of the box". Du möchtest Dich als in diesem Zusammenhang mal mit "Samba" (http://www.samba.org/) beschäftigen, weil "Samba" eine Implementation des SMB-Protokolls darstellt. Damit werden auf einem Linux-System Windows-Freigaben erzeugt. Da Active Directory auf den Punkt gebracht ein LDAP-Verzeichnisdienst ist, und LDAP eigentlich schon Standard unter Linux war, bevor das AD erfunden wurde ;-) kann ein "Samba"-Server das LDAP des AD nach Benutzern und Gruppen befragen und entsprechend Berechtigungen auf Verzeichnisse, Dateien und Drucker geben. Jedoch muß "Samba" hierfür die Windows-Domainen-Benutzer (geht auch mit Arbeitsgruppen) auf Linux-Benutzer abbilden. Ich hoffe, das reicht erstmal für den Anfgang - weil von mehr habe ich nicht wirklich mehr als eine Ahnung, was "Samba" angeht.

Greifen auf diesen Server Benutzer zu, die dort evtl. Benutzerlaufwerke haben? Könnte ja möglich sein, daß dort jemand einfach seine MP3-Sammlung in den Orkus gekippt hat. Alles schon gesehen :-|

Ist das kompliziert 8-| - Aber man lernt nie aus. Steht ja auch so bei MS: http://www.microsoft.com/learning/mcp/mcdst/requirements.asp Core Exams (Two Exams Required) Exam 70–271 / Exam 70–272

Nicht ganz: DC1: FSMO -> DC2 ein, zwei Tage (bis drei Wochen - je nach Umgebung) so lassen. DC1: zum Member-Server demoten ein, zwei Tage (bis drei Wochen - je nach Umgebung) so lassen. DC1: offline nehmen DC2: DC1 aus AD entfernen DC1: mit Windows Server 2003 bestücken DC1: als Member in das AD eintüten DC1: Zum DC promoten ein, zwei Tage (bis drei Wochen - je nach Umgebung) so lassen. Die FSMO-Rollen wieder auf den DC1 zu spulen ist eher eine Glaubensfrage. Technisch notwendig wohl eher nicht. Also ich würde es jetzt so belassen wie es ist.

Die Zertifizierungsprüfung ist ähnlich wie eine Führerscheinprüfung zu sehen, weil das richtige Autofahren lernst Du auch erst nach bestandener Führerscheinprüfung, wenn kein Fahrlehrer mehr neben Dir sitzt. Ich glaube, daß ich nach jeder einzelnen MCP-Prüfung mit Sicherheit ca. 90% sofort wieder vergessen habe, weil ich nun _immer_ nachschauen kann, wo eine Antwort in welchem Buch steht.

Rein theoretisch sollte man in der Lage sein in jedem zertifiziertem Testcenter die Prüfung in der Sprache seiner Wahl abzulegen, so denn das Testcenter für die entsprechende Sprache zertifiziert ist. Sprich: Wenn ich eine Prüfung in französischer Sprache machen will und die entsprechende Prüfung lokalisiert wurde, kann ich diese Prüfung auch in Spanien ablegen. Wahrscheinlich ist es eher so, daß ein deutsches zertifiziertes Testcenter alle Prüfungen in englisch anbieten kann und eben zusätzlich die verfügbaren lokalisierten in germanski. Diese Antwort kommt ohne Garantie auf Richtigkeit - Reine Vermutung ;-)

Kommt natürlich drauf an, wie groß Dein AD ist ;-) Im Ernst, wenn Du bisher nur einen DC hast, dann sollten wirklich ein bis zwei Tage völlig ausreichen. Hast Du jedoch ein AD mit 136 DCs in 180 Standorten ;-) solltest Du der Empfehlung von MS folgen. Ich kenne die Vorgabewerte aus Exchange Server 2003-Migrationen, wo in einer großen Umgebung (also wirklich großen Umgebung) zunächst ein forestprep gefahren wird und drei Wochen später dann das domainprep und wieder drei Wochen später das eigentliche Setup erfolgt. Allerdings hängen hier irre viele kleine und schwache Telefon/Internet/VPN-Verbindungen zwischen den DCs rum und die Benutzer wollen auch noch arbeiten können. Tipp: Zusätzlich halte ich es hierbei eigentlich so, daß ich Migrationen niemals nicht am Wochenende durchführe, wenn es sich nicht absolut vermeiden läßt. Hintergrund ist, daß wenn es zu Problemen kommt, habe ich so ziemlich keinen Support von irgendjemandem, weil die ja alle im Wochenende sind. Man kann entsprechende Verträge abschliessen, aber die kosten einfach mehr Euronen, als wie wenn (was für'n deutsch) ich einen Support unter der Woche vertraglich binden kann.

Sieht eigentlich alles ganz vernünftig aus, nur erlaube mir die Frage, warum Du die Keys wieder von den Systemen löschst? Du brauchst doch einfach nur "UseWUServer"=dword:00000001" auf "UseWUServer"=dword:00000000" zu setzen und schon wird aus einem WSUS-Client wieder ein Client, der sich die Updates wieder direkt bei Microsoft holt. Und wirklich interessant ist der Inhalt der "windowsupdate.log" im entsprechenden Installationsverzeichnis des Betriebsystemes. Da steht eigentlich genau drin, was schief gelaufen ist. Mit dieser Angabe kommen wir dann auch weiter.

Vom Prinzip her ist das mit dem Installationsdatum "auf gestern" setzen keine schlechte Idee, aber Du hast hier ein anderes Problem. Wie genau hast Du Deine WSUS-Clients eingerichtet? Wenn Du eine Gruppenrichtlinie benutzt, dann würde ich gerne die Einstellungen im Einzelnen vor mir haben, weil der Punkt "Updates sofort installieren" (aus dem Kopf) wahrscheinlich das ist, was Du willst. Dies bedeutet, daß der WSUS-Client die Updates sofort installiert, die keinen Reboot erfordern. Zusätzlich ist zu bedenken, daß Du einen bestimmten Patchlevel benötigst, damit aus einer Workstation auch ein WSUS-Client werden kann. Bei Windows 2000 ist das Service Pack 3 das absolute Minimum, aber Service Pack 4 kommt imho besser. Windows XP sollte "out of the box" funktionieren. Zusätzlich ist es so, daß bei Windows 2000 einige Updates mehr den Rechner neu starten wollen. Die gleichen Updates unter Windows XP gehen ohne Neustart durch.

Sicher Du hast recht, will ich auch gar nicht abstreiten :-D Dennoch ist die Prüfung auf einen MX-Eintrag (und zusätzlich auf einen Reverse-Eintrag auf den MX-Record) eine Überprüfung auf etwas, woran sich eigentlich zwingend niemand halten muß. Real existierend ist es jedoch die Vorhaltung eines MX-Records und entsprechend auch eines Revers-Eintrages auf einen MX-Record als "allgemeingültig" zu betrachten, also eine Art "Best Practice" ;-) Mir ging es eherum die Darstellung des technischen Standards und das es wohl langsam an der Zeit ist, jenen endlich entsprechend der Realität zu aktualisieren.

Ich muß an dieser Stelle gestehen, daß meine Kenntnisse über den MSX 5.5 wohl ein wenig eingestaubt sind. Und das obwohl ich noch bis September letztes Jahr produktiv mit MSX 5.5 gearbeitet habe :-| Sorry, an dieser Stelle muß ich mich ausklinken.

Nun also das mit der festen IP und gültigen Domain sehe ich genauso. Das mit dem MX-Record ist so eine Sache meiner Meinung nach. Es gibt technisch gesehen keinen Grund einen MX-Record zu haben, weil im Zweifelsfall versucht wird an den A-Record zuzustellen. Das ergibt zwar einen Aufruf mehr beim DNS-Lookup, aber mir ist aus der hohlen Hand kein RfC bekannt, der einen MX-Record zwingen vorschreibt.

Ahh, jetzt. In der Tat - ein Mistverständnis ;-) Du hast also ein Programm irgendwo, das ruft die eMails ab und stellt diese dann den entsprechenden Postfächern im MSX 5.5 zu. Dieses Programm ist ca. 24 Stunden fröhlich weitergelaufen, hat aber durch den Ausfall des MSX 5.5 kein Ziel gehabt. Ich würde also vermuten, daß die eMails sich in diesem Programm befinden. Gibt es dort auch sowas wie eine (wenn auch kleine) Warteschlange, die man irgendwie manuell auslösen kann? Dort würde ich jetzt mal zuerst suchen, weil das vielleicht einfacher geht bevor man in der Exchange-DB rumwühlt (wovon jemand anders vielleicht mehr Ahnung hat als ich - fleh).

Was möchtest Du denn erreichen? a) Die POP3-Benutzer sollen Ihre kompletten Outlookordner in eine PST-Datei sichern und Dir zur Verfügung stellen. Diese kannst dann mit Exmerge wieder in die Exchange-DB bringen. b) Die POP3-Benutzer sollen Ihre kompletten Outlookordner in eine OST-Datei sichern und Ihren Zugang als IMAP4 rekonfigurieren (so Du IMAP4 für den MSX 5.5 freischaltest). Dann können die Benutzer die PST-Datei als Persönlichen Ordner einbinden und über IMAP4 in die Exchange-DB "hochladen", in dem Sie die Nachrichten und Ordner einfach in den Posteingang des IMAP4-Posteinganges kopieren/verschieben. Beides wird jedoch nicht dazu führen, daß zwischenzeitlich "abgerufene" eMails wieder auftauchen. POP3 ist und bleibt ein Datensicherungsproblem beim Client und nicht am Server.

Mobotix ist doch so eine Überwachungskamera, richtig? Du sagst, daß Du Deine eMail-Adresse als Absender in der Kamera eingegeben hast, die Fehlermeldung bezieht sich jedoch nicht auf das "Mail From" sondern auf das "Rcpt To". Ergo: a) Welche Empfängeradresse hast Du eingestellt? b) Wenn Du die Kamera so einstellen kannst, daß diese sich mit SMTP-Auth am Exchange anmelden kann, dann solltest Du das bitte benutzen. Dies wird die Ursache für den "Rcpt To"-Fehler sein.

Es mag sein, daß 554 als Standardantwort definiert ist ... http://www.mimesweeper-infos.de/232.0.html [...] 554 Transaction failed (Transaktion fehlgeschlagen) bzw. bei Verbindungsöffnungsantwort: No SMTP Service here (Hier kein SMTP-Dienst) [...] ... aber das bringt Dich hier nicht weiter da nicht ausgeschlossen werden kann, daß ein anderes Problem vorliegt. In diesem Falle nämlich, _warum_ AOL Dir einen 554 auf Deine Verbindungsversuche gibt. Am einfachsten wird es sein, sich einfach mal die Webseite anzuschauen und da steht der Grund eigentlich ganz genau angegeben. <cut> * 554 RLY:CH http://postmaster.info.aol.com/errros/554rlych.html EXPLANATION: Your IP address has generated AOL member complaints and your mail system may be compromised due to a virus or other security related issue. </cut> Die Jungs von AOL arbeiten ziemlich schnell und wenn man entsprechend deren Online-Formularismus benutzt, dann bekommt man ziemlich schnell wieder direkten Zugang zu deren SMTP-Servern. Allerdings solltest Du Dir tatsächlich überlegen, Deine eMails über einen Smarthost zu jagen, wenn Eure Internetverbindung keine feste IP-Adresse hat. Dein ISP berät Dich hier sehr gerne.