Nimral

AOMEI Backup. Alles drin was man sich wünscht, incl. incremental/Differential und Historien-Verwaltung und E-Mail Versand des Backup-Status und ein Scheduler. Wermutstropfen bisher: Software Made in Fernost (China?), Deutsche Übersetzung an einigen (unwichtigen) Stellen gründlich daneben, E-Mail Support taubstumm, ich hätte da noch ein paar Fragen gehabt, Userforum Deutsch oder Englisch konnte ich keins finden. Vollumfängliche Demo ist verfügbar, !Vorsicht! Die Demo macht exakt 10 Backups, gibt aber keinerlei Warnung aus. Dass Du nach 2 Wochen plötzlich ohne Backup bist bemerkst Du nur, wenn Du die Backup-Dateien genau anschaust (Datum). ----- Ich habe es bei mir auf "jeden Wochentag" konfiguriert, das Ziel ist mein Netzwerkserver zu Hause (Home-Office). Um mehr kümmere ich mich nicht. Bin ich zum Backup-Zeitpunkt zu Hause im LAN, läuft das Backup irgendwann um die Mittagszeit, wo ich normalerweise sowieso zum Essen bin. Bin ich nicht zu Hause, bricht es ab, was mir egal ist, macht es eben einen Tag später. Die Variante mit "Freitags im Büro" würde genau gleich funktionieren, aber warum auf Freitag festlegen, die Incrementals laufen so schnell dass er meinetwegen auch jeden Tag sichern könnte (wenn ich jeden Tag im Büro aufschlagen würde). Einziger Mäkel bisher (nicht ernsthaft, man kann auch zu viel verlangen): wenn ich außer Haus, aber per VPN mit dem Home-Office verbunden bin, läuft das Backup ebenfalls los, da es meinen Home-Server per Namensauflösung finden kann. Kann bei schmalbandigen Anbindungen lästig werden, kann mir aber auch vorstellen, dass ich genau das haben wollte: Backup über VPN am Abend aus dem Hotel - der Traum jedes Außendienstlers. Armin (Der wettet, dass es auch noch 100 andere Client-Backup Tools gibt die das hinbekommen, aber das ist halt das eine das mir zugeflogen ist, und da es für mich gut funktioniert ...)

Nur der Volltändigkeit halber, nachdem die Reparatur + erneuter Test nach Stunden durch war: - WD "Data Lifeguard" Tool hat "repariert" - WD "Data Lifeguard" hat danach den "Extended" Oberflächentest durchlaufen, ohne wie beim 1. Mal am Ende eine Reparatur mit möglichem Datenverlust anzubieten - WD "Data Lifeguard" Log zeigt "PASS" in grüner Farbe - WD "Data Lifeguard" SMART unterschütterlich auf "Alles OK" --> ich denke, man kann sagen, dass laut "Data Lifeguard" die Platte OK ist. Der Server zickt nach wie vor, kann RAID1 mit 2. (selbes Modell) WD Platte nicht aufbauen, Windows Eventlog meldet einen defekten Block, unabhängiges Tool (HD Tune Pro) meldet einen defekten Block ... ich neige dazu (2:1), Windows und dem unabhängigen Tool zu glauben. --> Ich denke, man kann sagen, dass das WD Tool schummelt. Anbei noch Screenshots. Die Ersatzplatten kommen - trotz 5 Jahren Garantie - wenns nach mir geht sicher nicht mehr von WD. Armin.

Herzlichen Dank für den Tipp, NPI hat die Aufgabe gelöst. Die Datei war unwichtig, Glück gehabt. und der Thread da ist eine wahre Goldgrube, Doppeldank! Armin. 1- Nein. Niemals auf Dateiebene. Remember: ich hatte die Block- bzw. Sektornummer bereits in der Hand, und wollte wissen, welche Datei betropffen wäre, wenn ich den Block opfern muss. Siehe --> 2 2- Kenn ich, aber nochmal: Ausgabe der betroffenen Datei? Never ever. Im vorliegenden Fall: Western Digital Originaltool ("Data Lifeguard") laufen lassen. SMART Test sagt: DISK OK - kein Garantiefall (darum gings den Jungs also ...). Unabhängiges Tool laufen lassen (HDTune Pro): SMART Test sagt: Sector Read Error. Windows Event Log sagt auch: Read Error --> das WD Tool schummelt. WD Tool "Extended Tests" (Oberflächentest) laufen lassen, aha, jetzt wird angeboten, defekte Sektoren zu reparieren. SMART steht im WD Tool allerdings immer noch unerschütterlich auf "Keine Fehler". Warnung vom Tool: Datenverlust ist möglich. Meine Meinung: Datenverlust ist sicher, wo soll das Tool die defekten Daten auch herzaubern. Es wird also einfach ein Block mitten in der Datei durch irgendwelche Zufallsbytes ersetzt werden. Cooler Lösungsansatz. **Keine** Angabe, welche Daten es denn treffen würde. Daher meine Frage. NPI ergibt: alles OK, Datei ist unwichtig, kann weg. Ich lass das WD Tool daher "reparieren". Ist gelaufen, jetzt läuft gerade wieder der Oberflächentest, dauert paar Stunden, mal sehen ob der defekte Block ausgeblendet wurde. Die kaputte Datei habe ich gelöscht. Ich berichte ggf, wenn das WD Tool nochmal patzt. Naseweiser Hinweis: der reflexhafte Verweis auf das Tool des Herstellers ist m.E. ein schlechter Rat. Die Tools sind nicht unabhängig, überschreiten Grenzen, um Garantiefälle zu minimieren, und verursachen Datenschäden, die man u.U erst viel später oder gar nicht bemerkt. Und keins der mir bekannten Hersteller-Tools kann die defekte Datei benennen, was ja der Kern meiner Frage war. 3- DAS möchte ich sehen. Dazu müsste der Controller das File-System lesen und auswerten -- never ever. Und bevor der Tipp kommt: Ersatz-Disk ist bereits bestellt. Repariert hin oder her, die Disk wird getauscht, hat auch bereits 51,000 Stunden (6 Jahre) Laufzeit auf dem Buckel, der "reparierte" Defekt wird also nicht der letzte sein. Armin. (Bemüht, die Qualität der Informationen im Internet zu verbessern)

Hi allseits, ich suche mir seit einigen Tagen die Finger wund nach einer Möglichkeit, unter Windows Server (NTFS) festzustellen, welche Datenstruktur(en) von einem defekten Block belegt sind. Also welche Datei, welches Verzeichnis vom Ausfall des Blocks betroffen ist. Die Blocknummer ist aus dem Windows Event-Log bekannt. Hat jemand eine Idee? Thx, Armin.

Hi allseits, hab dazu im Forum nur einen alten Thread von 2010 gefunden, der ohne sinnvolle Antwort geblieben ist. Frage: ist es möglich, das Einrichten eines WLAN per Kommandozeile zu bewerkstelligen. Einsatz ist sowohl als Kommando im Rahmen eines unattended Setup als auch nachträgliches Verteilen von WLAN auf bestehenden Clients - eventuelle Parameter in einer unattended Steuerdatei nützen mir also nichts, da nicht alle Clients neu aufgesetzt werden sollen. Ein wenig Vorarbeit habe ich geleistet: Man nehme eine Maschine, und konfiguriere das WLAN (ich nenne es meinWLAN) von Hand, und teste es. Gut, klappt. Das Kommando netsh wlan export profile meinWLAN folder=c:\ schreibt die Settings in eine xml Datei, ich nenne sie mal meinWLAN.xml. Gut, klappt. Dann importiere ich die XML Datei auf der Zielmaschine: netsh wlan add profile filename=meinWLAN.xml user=all und tatsächlich, das WLAN wird in der Zielmaschine angelegt, Leider aber offenbar ohne WLAN Key ... lasse ich es verbinden, werde ich nach dem Key gefragt. Frage: hat jemand diesen Mechanismus in Verwendung, und klappt dort der Import samt Key? Wenn ja, mache ich mich auf die Fehlersuche. Wenns bei anderen auch nicht klappt, weiß ich immerhin, dass ich aufhören kann, meine Zeit mit diesem Thema zu verplempern. OS: Windows 7x64 mit aktuellen Patches. Thx, Armin.

Danke euch, das ist nützlich, wenns bei euch geht muss es auch bei mir gehen. Scheint dass ich bei dem Test einen alten Client erwischt habe, das wäre die einfachste Erklärung. Also zurück auf los, mit einem neuen Client. Und meinen Usern furchbar wichtig: die Adresslisten gehen natürlich mit, oder? Armin.

Aber - laut Meldung - nur ein Exchange Postfach. Ich kann 1 Exchange Postfach und x IMAP/POP Postfächer haben, aber keine 2 Exchange Postfächer. So der Stand. Wenn Du sagst, von Deinen Postfächern sind mindestens 2 Exchange Postfächer, mache ich mich auf die Suche nach meinem Fehler ... Armin.

Hu Dukel & Renegat, danke für eure Antworten, langsam habe ich das Gefühl ich treffe auf Leute die nachvollziehen können was abgeht. Leute die mir sagen dass sie schon x SBS mit Hilfe des Automaten erfolgreich und problemlos migriert haben finde ich zu Hauf, das bringt mich nicht eine Minute weiter. Es liegt im Wesen meines Jobs dass die Migrationen bei mir einschlagen die eben *nicht* erfolgreich durchlaufen, und dass es woanders geht hilft mir nicht. Ärgerlich ist allenfalls bei SBS, dass man es bei der Migration mit einem dummen Automaten zu tun hat. Entwerder läuft der durch, oder man ist in "deep shit". Ich würde es - Verbesserungsvorschlag an Microsoft - vorziehen, wie früher stundenlang Schritt für Schritt und Dienst für Dienst von Hand umzuziehen. Den Assistenten möge man sich bitte sonstwohin stecken, er ist keine Hilfe sondern ein zusätzliches Problem. Und keine Alternative anzubieten ist einfach nur doof ohne Ende, entspricht aber m.E. Microsofts Geschäftszielen, sich eine Riege von billigen Assistentenklickern heranzuzüchten, die dann bei Problemchen den Microsoft Support mit Consulting-Aufträgen versorgen. Über kurz oder lang wird Microsoft - aber das ist OT und soll nicht diskutiert werden - den Support und damit verbunden auch das Consulting so wie bereits das Thema Trainings zwangsweise zu sich ziehen, Myriaden kleiner und mittlerer Dienstleister im Windows Umfeld werden - wie davor schon den "Schulungspartnern" - die Kunden weg zu Microsoft abgezwungen. Ich hoffe für alle Windows Consultants, dass sie ihre Schäfchen im Trockenen haben, denn in Zukunft macht Microsoft das Geschäft selber, ihr seid nun überflüssig. EEE. Embrace, Extend, Extinguish. Renegat, Deine Lösung ein AD per Backup/Restore von 2003 auf 2008 umzuziehen in Ehren, und Hut ab vor Deinem Mut, aber die Wahrscheinlichkeit dass das nebenwirkungsfrei und zukunftssicher funktioniert, wenn überhaupt, halte ich für sehr gering. Duke: das mit dem zusätzlichen DC ist mir theoretisch bekannt, und ich hätte sogar - möglicherweise - die richtige Software, da SBS 2008 eine "Pro" Version ist, ist eine Serverlizenz für einen weiteren 2008 samt Medium mit dabei. Aber wie würde mir das helfen? Gut, ich könnte nun 2008 Server auf dem neuen Server oder in einer VM installieren. Was dann weiter? Nehmen wir an, ich könnte ihn zum DC hoch- und den alten SBS irgendwie herunterstufen, auch noch gut. Aber was dann? Ich müsste dann irgendwie den SBS 2008 in die bestehende Domäne reininstallieren, und daran bin ich ja schon einmal gescheitert, da die SBS 2008 Installation, wenn man nicht per Steuerdatei und Assistent vom SBS 2003 weg migriert, nur "neue Domäne" akzeptiert. --> ich drehe mich im Kreis, wie genau würdest Du vorgehen? Thx,, Armin.

Ach wo, ich bin nur unglaublich gefrustet. Nach 4 Tagen Kampf gegen einen zickigen Small Business Server. Alternativ könnte ich irgendein Stück Hardware gegen eine Wand schmeißen, sieh es als verbale Ersatzhandlung. Exchange Version lokal ist 2003, Version Hosted Exchange dürfte 2013 sein (1und1), genaues weiß nur der Provider, und als Endkunde sollte ich mich mit dieser Frage ja auch nicht beschäfigen müssen. Outlook ist 2010 (eigentlich), oder 2013 (auf Anraten des Provider-Supports soll ich alle Clients "vorsichtshalber" mit dem neuesten Outlook betreiben). Gruss Armin.

Für jemanden, der sie jemals gesehen hat, sind sie aussagekräftig, und jemand Anders kann mir nicht helfen. Ich habe sie leider nicht wörtlich mehr im Kopf, und sie wieder produzieren - 2 Stunden Arbeit, incl. Neuaufsetzen des alten SBS nach der Prozedur, das wollte ich mir sparen. Und blablabla, weil die Meldungen völlig offensichtlich Unsinn sind. Der Witzbold (um den Wizard mal anders zu nennen) behauptet, er könne die AD Synchronisation nicht abschließen, weil sie zu lange dauere. Wenn ich nicht auf die Meldung reagiere, kann ich derweil per Task-Manager einen Blick ins Active Directory werfen, und siehe da: alle meine Konten wären auf dem neuen Server vorhanden. Nur dass er die ganze Installation ruiniert, in dem Moment, wo ich den Witzbold dann irgendwann abbreche, und was anderes bleibt mir ja nicht übrig. Nach 4 Tagen Frust und Ohrfeige um Ohrfeige von diesem zickigen Miststück von einem Server, in der zweitletzten Nacht vor Deadline (morgen kann ich noch murksen, am Montag kommen die User aus dem Urlaub, und dann geht der Tanz los) erlaube mir ein wenig Frust. Die Aussicht auf ein langes Wochenende behagt mir absolut nicht. Und danke für den Blog-Mitschnitt, ich hatte ihn glaube ich vorgestern am späten Nachmittag auch ausgegraben, der einzige Hinweis auf AD Sync Probleme weist auf den FRS Dienst hin, aber der ist laut Diagnose OK, und der Blog widerspricht in vielen Details dem offiziellen Microsoft 82 Seiten Pamphlet - wem soll ich jetzt glauben? Und man fragt sich - wenn schon der FRS Journal Warp eine häufige Problemquelle ist - wieso der Best Practice Analyser ihn wohl übersieht, und wenn dem so ist, was der Best Practice Analyser denn noch so alles übersieht, und wozu er überhaupt gut ist, wenn er gravierende, bekannte Probleme übersieht. Daher meine Einschätzung, dass es sich wohl eher um einen bunt angemalten *** als einen "Analyzer" handelt. Armin.

Hi allseits, da ich eventuell eine Chance sehe, nicht in jeden Microsoft Müllkübel knietief waten zu müssen, hier eine schnelle Rückfrage, ob das was ich machen will so wie ich es machen möchte klappt und Sinn macht. Ihr erratet es bereits, ich bin bereits seit fast einem Jahrzehnt, nach einem kurzen Überschlag Kosten/Nutzen, ein Outlook-los glücklicher Mensch inmitten einer Office - Outlook zwangsbeglückten Userschar. Nun rächt sich das, denn bisher bin ich der einzige, der einen plötzlich vom Himmel gefallenen Umzug von Exchange (lokal) auf Exchange (Hosted) mit einem Schulterzucken und zwei Mausklicks hinter sich gebracht hat, aber nun soll ich auch allen anderen helfen. Autsch. Ein wenig Zeit hat mir das Schicksal zugespielt: derzeit klemmt noch das Anlegen der Postfächer beim neuen Provider, aber das ist sein Problem. Von 6 konfigurationstechnisch gleichen, testweise angelegten Mailkonten liefen zwei sofort (meins, und noch eins, und "sofort" heißt ca. 30 minuten nach Eingabe in ein Webinterface), Zwei wurden angeblich angelegt und verschwanden nach einer Weile im Nichts, ich kann sie vermutlich wieder anlegen wenn ich Lust drauf habe, und zwei hängen noch irgendwo zwischen Nichts und Exchange in irgendeinem Business-Prozess (hochgestochenes Wort für einen mehr oder weniger dämlichen Script), ich kann mit denen derzeit weder vor noch zurück, der Provider schlägt sich gerade damit rum. Gut, ich denke, innerhalb der nächsten paar Tage wird er seinen Exchange in den Griff bekommen, und ich bekomme dann alle Postfächer angelegt. Jetzt wären allerdings noch die alten Postfachinhalte, also Mails und Termine, umzuziehen. Mein erster Plan war, beide Konten im Client anzulegen, und dann die Daten vom User per Mausschubs umziehen zu lassen, aber Pustekuchen, der entsprechende Microsoft "Assistent" (um nicht wie sonst ein Schimpfwort zu gebrauchen) belehrt mich, dass man nur ein Outlook Konto zu einer Zeit haben darf. Also ist der zweitbeste Plan: gesamtes altes Exchange Postfach per Outlook in eine pst Datei kippen, altes Konto/Profil löschen, neues anlegen, Daten wieder importieren. Alle behaupten, dass das so einfach geht, incl. dem Support vom Provider. Ich wäre positiv überrascht, aber ich rechne mal mit dem Schlimmsten, Und die User kriegen das niemals hin. Also werde ich das Relais spielen, die User erstmal einige Tage von Outlook weg auf Outlook Web Access zwingen, da können sie dann neue Mails bearbeiten, und währenddessen im Hintergrund mit meinem Outlook den Datenschubser für die alten Daten spielen, und dann bei denen, die nicht sowieso bei OWA bleiben, das lokale Outlook umkonfigurieren. Da die Useranzahl überschaubar ist, mache ich das, ich denke dass das weniger Aufwand ist wie wenn ich versuche, die User durch die MAPI Konfiguration zu schicken. Und jetzt die Frage: klappt das so wie ich es mir denke, oder muss ich noch irgendeinen Voodoo treiben damit das klappt? Oder ist das ganze sowieso eine ganz schlechte Idee? Thx Armin.

Das war doch die Frage, die ich nicht gestellt haben wollte, denn sie bringt mich nicht entscheidend weiter. Pragmatisch: Microsoft hat einen 2008-er SBS produziert und auf die Welt losgelassen, als offiziellen Nachfolger von SBS 2003. Sag mir einen Grund, warum ich ihn (auch 2015) nicht installieren sollte? Eines von den greifbareren Argumenten - abgesehen davon dass Exchange bei den neueren Versionen nicht mehr dabei ist - weil ein SBS 2008 samt CALs gerade unbenützt rumliegt, bezahlt, und weil sich auf dem alten SBS noch eine Custom-Software der besonderen Art herumtreibt, die auf den SBS - und nur auf den SBS - lizensierbar ist. Ein SBS muss also leider bleiben, aber er soll unter 2008 laufen, nicht unter 2003. Und die Domäne zu verlieren wäre ein herber Schlag, ich muss Dir vermutlich nichts erzählen über Konten, SIDs und Berechtigungen und was der Totalverlust allen dessen bedeuten würde, wenn ich eine neue Domäne eröffnen müsste. Was hätte sich denn konkret geändert, wenn ein "richtiger" 2008 Server herumgelegen wäre? Außer dass man in einen ganzen Folge-Müllkübel von Problemen langen würde, da der 2008 Server mit den bestehenden, bezahlten CALs des SBS wohl kaum abzuspeisen wäre? Armin.

Der "Migrationstrolltel" kommt im Dreierpack. 1.) "Best Practices Analyser". Der meint nach eingehender Beäugung des bestehenden 2003 SBS dass alles OK sei. 2.) SBSAfg "was auch immer das genau heißt" produziert eine Steuerdatei für den dritten ***, den man per USB Stick an den neuen Server beim Setup verfüttert (Bemerkung am Rande: der USB Stick stört bei meinem Server den 2008 Setup - man muss also genau aufpassen wann man ihn in den neuen Server steckt) 3.) Wenn die Steuerdatei vorhanden ist, wird sie auf dem SBS 2008 vom "Migration Wizard" (er nennt sich Zauberer, ich nenne ihn ***) aufgepickt, und der hängt dann irgendwann. Da er vorher bereits ganz offensichtlich intensiven Kontakt mit dem alten SBS hatte darf man mutmaßen, was für Schäden er bis dahin angerichtet hat. Ein Restart der Migration ist wohl nicht vorgesehen - wenn man den Zauberer irgendwann abbricht, wird man zwangsabgemeldet. Danach fährt sich der SBS 2008 runter, ich kann ihn wieder hochfahren, mich anmelden, aber er fährt sich sofort nachher wieder runter. --> Kabumm

Hi allseits, ich habe einen SBS 2003 (SP2 Server) "geerbt". Er soll nach SBS 2008 migriert werden (bitte keine Fragen nach warum und wieso, und warum nicht 2011/2013/2099/Cloud/Linux oder Betamax - es ist legitim, es ist (theoretisch) möglich, es soll so gemacht werden. Trozu peinlichst genauer Befolgung des Microsoft Leitfadens zur Migration (82 Seiten Ding) und penibler Nachinstallation der diversen KB Fixes und Service-Packs (oder jünger) fällt der Migrationstrottel, zu dessen Benutzung man ja gezwungen wird, auf dem Zielserver beim Versuch, das AD zu übernehmen, auf die Nase ("Synchronisation dauert zu lange, blablabla"), und die SBS 2008 Installation/Migration bleibt hängen. Das Resultat ist ein möglicherweise kaputter SBS 2003, und ein sicher kaputter SBS 2008, da von ersterem allerdings ein Image-Backup existiert kann er das Spielchen ruhig öfter treiben - nur gehen mir langsam Zeit und Geduld aus. Also anders rum? Auf den migrationstrottel verzichten? Ich kann SBS 2008 auf der Zielhardware durchaus installieren, aber ein weiterer Installationstrottel zwingt mich, den SBS sofort als Domänen Controller einer *neuen* Domäne in Betrieb zu nehmen. Ich brauche ihn allerdings als extra Controller in der alten Domäne, nur - diese Option bietet der Installationstrottel nicht an, und ihn abzubrechen bedeutet, dass der Server sofort herunterfährt und mir den Mittelfinger zeigt. Entweder DC, oder Shutdown. Ich habe dann versucht, den SBS 2008 in einer neuen Domäne aufzusetzen (klappt natürlich), und ihn dann zu demoten, in de rhoffnung dann einen blanken Server zu bekommen, den ich als DC zur SBS 2003 Domäne dazuhängen kann, dann hätte ich schon mal viel gewonnen. Pustekuchen. Das Demoten klappt, aber beim versuch den Server dann mit DCPromo in die 2003-er Domäne zu schicken hängt DCPromo bereits ganz am Anfang mit eienr Meldung, dass (sinngemäß) "die Installation der Domänen-Software nicht verifiziert werden kann" + Endlosschleife. Gibt es eine reguläre Möglichkeit, den neuen Server mit SBS2008 als DC der bestehenden SBS 2003 Domäne hinzuzufügen, dann die FSMOs zu transferieren, und den alten SBS 2003 schließlich zu entsorgen? Es geht mir ganz bewusst - und ich weiß was ich tue - nur um die Domäne und die Domänenkonten. Es ist nicht notwendig, Exchange, Sharepoint oder SQL zu migrieren, weil die Postfächer sowieso auf einen andern Mailserver umgezogen werden, udn SQL und Sharepoint wurden nie benutzt. Es reicht, wenn der alte SBS noch sagen wir mal eine Woche als DC oder als Member-Server weiter läuft, bis auchd er letzte User sein Postfach (per Outlook Export/Import) auf einen anderen Mailserver umgezogen hat, einige sind grad im Urlaub. Für nützliche Tipps wäre ich dankbar. Thx Armin.

OWA for Android sah zwei Zeilen lang tatsächlich nach etwas aus was man erwägen könnte, bis ich las: "Support for on-premise Exchange servers will be announced in the future.". So lang die Zukunft noch in der Zukunft liegt wirds also nichts mit diesem Ansatz. Zugriff auf den Kalenderordner sollte gehen mit https://<Exchange-Server/owa/<user@domain>/#path=/calendar DAS schaut nun nach genau dem aus was ich gesucht habe! Werds gleich morgen früh im Büro austesten. Herzlichen Dank, Armin.

Die Plattform unter dem Browser ist Android ... ich wüsste nicht, dass man da einen Single Sign On machen könnte. Gruss Armin.

Hi allseits, ich habs geschafft, eine Webseite zu erstellen, die einen automatischen Login bei Outlook Web Access durchführt, mit der Form-Post Methode: <form action="https://.../owa/auth/owaauth.dll" method="POST" name="logonForm" ... Klappt, mit dem Klartextpasswort im html Code kann ich leben. Jetzt möchte ich aber nach dem Login den Kalender statt dem Posteingang angezeigt haben, oder - alternativ - per Programm automatisch zum Kalender wechseln. Kennt jemand eine Methode, dies zu erreichen? Danke für eure Hilfe Armin

"always prefers a domain controller that resides in the site of the client that is searching for a domain controller" So wie ich die AD Doku kenne versteht die Microsoft AD Truppe unter einer "Site" stets eine AD SIte, und die hat mit der Netzwerk-Infrastruktur nicht unbedingt viel zu tun. Sobald mehrere IP Netze in einer Site zusammengefasst sind hat der CLient - soweit mir bekannt - keine weitere Intelligenz, unter den angebotenen DCs den Besten zu wählen. oder sich -darum gehts mir im kern - einen DC "vorschlagen" zu lassen. Per Zufall einen aus der Liste nehmen kann er ja immer noch, wenn sich mein Vorschlag als ungut erweist, weil genau diesed DC ausnahmsweise down ist. Nicht erzwingen. Nur die Liste der Vorschläge sinnvoll sortieren. Normalerweise ist das der Sinn einer Site. Im Moment habe ich ein Netz, das vor 10 Jahren auf Grund der damaligen Gegebenheiten mit einer Site pro Standort geplant wurde. Nun ist man mit dem Systemverhalten nicht mehr zufrieden. Abhängig von den Site-Replikationsinstellungen kommen Daten wie z.B. DDNS Einträge sehr verzögert auf die andere Seite. Die Leitungen sind dicker geworden, also könnte man erwägen, das gesamte Netz als eine Site zu fahren. Man möchte aber nach wie vor sichergestellt haben, dass die lokalen Server sooft als möglich den Vorrang bekommen, wenn übergreifende Dienste, z.B. Domänenanmeldung + Rattenschwand an Scripten und GPOs (mein Thema) oder aber auch andere vergleichbare Dienste (DFS, nicht mein Thema) angesprochen werden. An sich wärs ja simpel: der Client kennt seine IP ADresse, es wäre kein Hexenwerk wenn er bei der Auswahl der Domänencontroller seiner Site einen mit einer IP Adresse im selbem Netz wie er selbst bevorzugen würde, statt - Stand meines Wissens - alle DCs seiner SIte als "gleich gut geeignet" zu betrachten. Dass er, wenn sein SIte-DC down ist, doer wenn es in seiner SIte gar keinen DC gibt selbstverständlich einen anderen DC nehmen darf versteht sich von selbst. Darüber hinaus stammen die gängigen Dokus zum Thea "Wie wählt ein Client einen DC aus) mehr oder weniger vollständig aus WIndows 2000 und 2003 Umgebungen. Man muss immer damit rechnen, dass 2008 hier neue Möglichkeiten bietet, von denen ich bisher einfach nichts gehört habe. Armin.

Hi Günther,. Ich fürchte da findet sich nichts was auf mein Problem passt. Um die Intersite-Replikation zu nützen wurde über die IP Subnetze drüber immer schon nur eine Site konfiguriert. Diese hat allerdings mehrere Domain Controller, und ich möchte sicher stellen dass die Clients einer Seite "ihren" Domain Controller bevorzugt nützen. Die Clients müssen sich also an den IP Adressen orientieren, und nicht an der Site Struktur. Oder es gibt eine Möglichkeit, einen "Preferred" Controller einzustellen. Das wäre meine Lieblingslösung. Lg Armin.

Hi allseits, nehmen wir an, wir hätten 2 "weell conencted" IP Subnetze, und eine gemeinsame AD Site drüber gelegt. Nehmen wir weiter an, es befände sich ein DC in jedem Subnetz. Nach allgemeiner Logik würden die Clients sich per Zufalll einen der DCs aussuchen, da sie in der selben Site liegen.. - Sind die Clients (XP, W7) eventuell schlau genug, "Ihren" DC (der mit der IP ADresse aus dem gleichen Subnetz) zur Anmeldung vorzuziehen? - Kann man eventuell "nachhelfen", d.h. Clients einen DC vorschlagen den sie nützen sollen, sofern dieser verfügbar ist? Link zur entsprechenden Doku reicht, lesen kann ich selber. Thx Armin.

Hallo allseits, ich habe auf der Suche nach probleme mit Ordnerumleitung eine größere Anzahl Windows Clients (XP, W7 querbeet) gefunden, die folgendes Verhalten haben: Bei User-Accounts, bei denen im AD ein HomeDirectory Pfad hinterlegt ist, z.b. H: --> \\server\homeshare\username\data\my documents wird dieser Pfad unterschiedlich auf Umgebungsvariablen verteilt: (1) %HOMEDRIVE%: H: %HOMESHARE%: \\server\homeshare\username\data\my documents %HOMEPATH%: \ (2) %HOMEDRIVE%: H: %HOMESHARE%: \\server\homeshare %HOMEPATH%: \username\data\my documents Ich konnte bisher keinen Konfigurationsunterschied bei Client oder User-Account identifizieren der dieses Verhalten auslöst. Bei Variante (2) kommt erschwerend dazu, dass dieses Verhalten offenbar nur während des Logins gegeben ist: dumpe ich die Variablen aus einem Login-Script in eine Datei, bekomme ich die Werte nach (2). Dumpe ich auf dem selben Computer mit dem selben User Account die Variablen nach der Anmeldung, also von der Kommandozeile aus, bekomme ich die Variablen nach (1) auf den Schirm. Die Verbindung nach H: funktioniert bei beiden Varianten, die User bemerken also den Unterschied gar nicht. Das trifft derzeit etwa 150 Maschinen (bzw. User, da idR jeder User eine Maschine benützt). Einige tausend andere Maschinen zeigen dagegen sowohl im Login Script als auch nachher die Variablen *imme*rnach Variante (1). Hat jemand eine Erklärung, welcher Auslöser dieses eigenartige Verhalten auslöst? Es würde mir schon reichen wenn jemand eine Einstellmöglichkeit kennt, regulär das Maschinenverhalten von (1) auf (2) umzustellen, die Computer sind ein ziemlicher Verhau was Einstellungen betrifft, und ich kann nicht ausschließen dass irgendwer irgendwo irgendwann absichtlich oder unabsichtlich ein Schalterchen gesetzt hat, das jetzt nach hinten losgeht. Das Netz abgegrast habe ich auch schon, es gibt sporadisch ratlose Anfragen von Leuten die dasselbe Verhalten bemerken, und es nicht erklären können, und in den Tiefen der MS Dokus fand ich auch nichts Erhellendes. Nach 4 Tagen (!) erfolgloser Suche und Rumprobiererei bin ich für konkrete Hinweise dankbar, Armin.

Hallo Leute, cih soll ein AD flicken, bei dem sich zwei Server (M1 und M2) nach einer längren Netzwerktrennung (4 Monate!) weigern, mit zwei anderen Servern (RC1 und SC1) kontakt aufzunehmen. Als vermutlich "unterste" Fehlermeldung konnte ich Eventlogs von Kerberos identifizieren: Fehler 5: KRB_AP_ERROR_MODIFIED. Computerkonto abgelaufen, oder eventuell doppeltes Computerkonto (kann man ausschließen). Nun ja, unlogisch wärs nicht, dass irgendwas, ich vermute mal die Computerkonten von M1 und M2, auf RC1 und SC1 abgelaufen sind. Leider ist es mir nicht gelungen, hier irgendeine vernünftige Diagnose zustande zu bringen, da praktisch alle Befehle sofort mit "Access denied" abgebügelt wurden, darunter auch Netdom pwdreset, und Befehle wie DCDiag schütten praktisch von der ersten Sekunde an den kompletten Bildschirm mit abstrusen Meldungen zu - vermutlich lauter Folgefehler einer grundlegend gestörten Kommunikation mit SC1 und RC1 und allen FSMOs. SC1 und RC1 kommunizieren augenscheinlich problemlos miteinander, ebenso M1 und M2, nur zwischen den beiden klafft ein Graben. Trivialquatsch wie DNS und IP Probleme wurden bereits sicher ausgeschlossen. Es würde vermutlich klappen, M1 und M2 zu demoten und dann wieder in die Domäne zu promoten, aber dieser brachiale Weg ist für mich ziemlich der allerletzte Ausweg, da die von M1 und M2 gesammelten Daten - tolles Design, aber es kommt nicht von mir - in ein schemamodifiziertes AD gekippt wurden, und ich diese vor einem depromote erst mühselig von den Anlagen kratzen muss. Außerdem ist das Anlagenverhalten so nicht tolerierbar, wenn ich es nicht schaffe, die Kommunikation mit ein paar beherrschbaren Befehlen sauber wiederherzustellen ohne eine Seite abzureißen muss sie grundlegend redesigned werden. Schließlich kann man nicht jedes Mal, wenn ein Container zurückkommt, eine halbe Domäne abreißen und neuabuen müssen. Auf der Suche nach KRB_AP_ERROR_MODIFIED habe ich ziemlich ins Leere gelangt, ein paar sporadische Fitzelchen Halbinformation weisen in Richtung "Abgelaufenes Computerkonto". Leider sind so ziemlich alle dafür angebotenen Workarounds, von netdom über Computerkonten-Reset mit der Users und Computers Konsole bei einem Domänen-Controller entweder nicht möglich, oder sie endeten in Access Denied Meldungen. Als wahrscheinlichste Ursache vermute ich im Moment eine klassische Katze, die sich in den Schwanz beißt: M1 und M2 versuchen, sich mit unpassenden Credentials bei SC1 und SC2 zu authentifizieren, können aber genau deswegen auch keine korrekten Informationen beziehen. Sorry wenn ich mich schwammig ausdrücke, aber irgendwo hier unten enden meine Kenntnisse über die interna von Computerkonten und Kerberos, und dummerweise auch die MS Dokumentation, in ziemlich unbrauchbaren Fetzen von zusammenhanglosem und teilweis widersprüchlichem Halbwissen. Gretchenfrage: wie zieht sich ein Computer, dessen domänenseitiges Konto ohne sein Beisein abgelaufen ist, wieder aus dem Sumpf? Irgendwie muss er wohl an neue Anmeldeinfos, Schlüssel, Zertifikate, was weiß ich, kommen, kann aber nicht, da er keine sichere Verbindung zum Zielserver hinbekommt. Wer kann mich mit der nase auf die richtigen Infos stoßen wo ich fundiert nachlesen kann, wie der ganze Mechanismus funktioniert und wie man hier Diagnose betreibt? thx AL.

Keine Angst, Robocopy gehört auch in meiner Toolbox zum Standard, wenn ich mal wieder in die Niederungen von Batches abtauchen muss. Im vorliegenden Fall ist WSH per Vorgabe gesetzt, warum ich Shell-Aufrufe für drittklassige Lösungen halte habe ich begründet (Du magst jetzt einwenen, dass CopyHere auch nichts anderes ist, sogar dümmer als Robocopy, der würde mir immerhin einen Errorlevel melden wenn ihm was nicht passt, während CopyHere auf toter Mann macht - ich würde Dir recht geben, aber in diesem Fall gebe ich "ist im Standardlieferumfang mit eingebaut" höhere Priorität) und ich bin ein sturer Hund und möchte das Ganze so haben wie ich es haben will. Danke trotdzem, und Robocopy ist ein gutes Tool, Armin.

Nope. Nach Aufruf von CopyHere wartet das Script brav, bis der copy beendet ist. Hab jetzt einen Workaround gebastelt: schaue nach, ob das Zielfile schon vorhanden ist, wenn ja, lösche es, dann mach CopyHere und schau nochmal nach, ob es nun vorhanden ist. Wenn ja --> alles OK, wenn nein --> irgendein Fehler muss wohl aufgetreten sein. Mit dem Block-Copy scheine ich unter WSH kein Glück zu haben :( Habe inzwischen eine "Lösung" gefunden, das Array of Byte mit einem String nachzubilden, das Ganze ist allerdings wegen des enormen Overheads bei jedem eizelnen Byte so grottenlahm, dass ich es gleich wieder gelöscht habe. Armin.

Hi Sigma, meine Begeisterung ist inzwischen gegen null gesunken: CopyHere gibt offenbar keinerlei Fehlercode zurück! Damit ist dieser Filecopy ein Schuss ins Dunkle, und für das Automatisieren von Abläufen leider unbrauchbar. Wäre zu schön gewesen, aber mal sehen, eventuell bekomme ich ja doch noch Plan A zum laufen .-) Armin.