prival

Ich bezog mich auch auf den letzten Post von Roi, welcher dem Post von Nils widersprach. @Weingeist: Sorry, dazu kann ich nichts sagen. Gruß, Prival

Auch wenn der Artikel schon etwas älter ist, möchte ich den doch gern ergänzen, weil hier fehlerhafte Infos vorliegen. Die Einschränkung von 260 Zeichen liegt in der verwendeten API, die so ziemlich jedes Programm, inklusive dem Explorer, nutzt. NTFS kann Pfade mit circa 32.767 UTF-16 Zeichen verwalten. Quelle: https://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx#maxpath. Und UTF steht für Unicode Transformation Format. ;) ReFS ist auch den Einschränkungen der API unterlegen. Demzufolge kann ein File Server mit ReFS auch keine längere Pfadnamen verwalten. Das ist nicht nur graue Theorie, das habe ich bereits intensiv getestet, weil wir hier öfters die Problematik mit zu langen Pfadnamen haben. Aktuell ist ReFS ganz nett, aber die Einschränkungen machen es derzeit nicht wirklich attraktiv. Klar, wer Stabilität sucht, wird sie bekommen. Schneller als NTFS ist es nicht, im Gegenteil. Die Unterstützung durch andere Produkte (Dritthersteller) ist oft fraglich. Aber ReFS wird weiter entwickelt, wie es auch bei NTFS war. Microsoft ist dafür bekannt, dass es früh Technologien auf den Markt wirft und den Kunden als Tester verwendet, um das Produkt weiter zu verbessern. Daher sehe ich persönlich noch davon ab. Bin aber sehr gespannt auf die kommenden Versionen. Bis dahin werden hoffentlich viele Hersteller ReFS in ihre Produkte (Backup, Archivierung, etc.) implementiert haben und gut funktionieren. Bisher ist mir das aber noch zu experimentell, um es produktiv zu nutzen. Gruß, Prival

In Zeiten von VLAN gibt es da keinen großen Overhead. Diese Maßnahmen werden nur einmal durchgeführt. Bei einer Offline CA hast du dagegen regelmäßigen Verwaltungsaufwand. Bitte nicht falsch verstehen, ich verteidige hier keine Online CA, ich zeige nur weitere Aspekte auf. Der Einsatz einer Online CA kann bspw. in einer kleinen Unternehmens- oder Testumgebung sein. Da obsiegt die vereinfachte Administration über den Sicherheitsgedanken. @Dunkelmann: Ich verstehe deinen letzten Satz nicht, sorry. Was will uns das über Online oder Offline sagen?

Musst du auch nicht. Wenn du nicht willst, einfach gar nicht antworten. Ehrlich gesagt ging das gar nicht in deine Richtung. Im Sinne der freien Meinungsäußerung und weil der Threadstarter alle Aspekte einer PKI wissen wollte, habe ich das Thema ergänzt. ;-)

Ein Grund eine Root CA online zu betrieben, kann der Verwaltungsaufwand sein, der bei einer Offline Root CA durchaus höher ist. Durch Härtung des Servers einer Online Root CA kann man eine gewisse Sicherheit schaffen. Wenn dann noch durch separiertes Netzwerk mit entsprechend konfigurierter FW dieses Netz abgeschottet wird, ist für eine rein intern genutzte PKI das Sicherheitslevel völlig ausreichend. Sollte die Root CA wirklich mal ein Opfer werden, dann verschiebt man die Zertifikate der CA's mittels GPO in den Speicher der "Nicht vertrauenswürdige Zertifikate" und gut.

Backup ins Netzwerk ist seitens M$ reglementiert. So kann man zwar ein DCs ins Netzwerk sichern, jedoch funktioniert die Wiederherstellung nicht. Es gab, tief aus der Erinnerung ausgegraben, aber noch andere Einschränkungen. Ich glaube Bare Metal geht auch nicht. Ich empfehle daher grundsätzlich Backup auf direkt angebundene Storages. Was dir jetzt allerdings nicht weiterhilft. Ich würde versuchen, die Daten auf eine externe Platte zu kopieren und dann an den Server anzuschliessen. Nach kurzer Recherche habe ich zum Thema DC-Backup auf Netzwerk noch was gefunden. Scheinbar kann man die Einschränkung mit einem Regkey beseitigen. Wenn ich das richtig lese, muss dafür vor der Sicherung dieser Key gesetzt werden: "http://technet.microsoft.com/en-us/library/cc771139(v=ws.10).aspx".

Sorry für die späte Antwort. Ich habe es erst jetzt gesehen. Muss mal meine Benachrichtungen checken. *kopfkratz* Zum Thema. Was der Event Viewer meint ist, dass eine Domäne in der Regel mehr als einen DC hat. Dann sollte unbedingt ein anderer DNS als erster Server eingetragen sein. Andernfalls erhältst du unter ungünstigen Umständen das Insel-Phänomen. Sollte es allerdings der einzige DC sein, bspw. in einer Testumgebung, dann kann man diese Warnung ignorieren. Hast du dein eigentliches Problem mittlerweile gelöst?

Wurde bi- oder unidirektional eingerichtet? Wenn es sich um einen unidirektionalen Trust handelt, sieht man die Vertrauenestellung nur in eine Richtung. Wurde der Trust auf beiden Seiten eingerichtet? Sieht man in Domains & Trusts (domain.msc) die Subdomain? Wenn ja, wurde der Trust über die eingebaute Funktion validiert? Zusätzlich kann man mit NETDOM TRUST /Verify den Trust prüfen. €DIT: Namensauflösung der Domains in beide Richtung muss funktionieren. Prüfe das nochmal. Außerdem steht im Eventlog sicher einiges an Fehlern oder Warnung dazu drin. Da würde ich mit ansetzen.

Hi, wir stehen vor dem selben Problem. Wie hast du diese Aufgabe gemeistert? Viele Grüße

Was ist denn aus deinem Problem geworden? Konnte es gelöst werden?

Dieses Problem tritt immer dann auf, wenn man die Site-Bezeichnung ändert. Eine langwierige Lösung ist die Reinstallation der CAS-Rolle. Eine einfachere und damit präferierte Lösung ist die Entfernung und Neuanlage des OWA-Directories. Das geht innerhalb von 5 Minuten über die Exchange PS. 1.) Auflisten der OWA-Directories und notieren der Identity des betroffenen virt. Verzeichnisses Get-OwaVirtualDirectory |fl 2.) Entfernen des OWA-Verzeichnisses Remove-OwaVirtualDirectory -identity "<Identity>" Bsp: Remove-OwaVirtualDirectory -identity "EXCH2010\owa (preprod.contoso.com)" 3.) Installieren des OWA-Verzeichnisses New-OwaVirtualDirectory -Name "owa (<Website Name>)" Bsp Installation in die Standardwebsite: New-OwaVirtualDirectory -Name "owa (www.contoso.com)" Bsp Installation in eine Nicht-Standardseite (Website-ID größer 1): New-OwaVirtualDirectory -Name "owa (www.contoso.com) -WebsiteName "Contoso Website" Voila! Die Anmeldung funktioniert wieder. Bitte beachte, dass du die Einstellungen (URLs, SSL, etc.) des OWA wieder anpassen musst. Die vorherige Config wurde ja mit gelöscht. Weitere Infos zu diesem Problem findet sich auch hier: Source: MSExchange OWA Event ID: 64 (Exchange 8.0) - Technet Events And Errors Message Center: Message Details Viel Erfolg.

Wie ich schon sagte, diese Anmerkungen helfen niemanden. Hier handelt es sich um einen Worst Case-Szenario dass eben so gestaltet ist. Niemand ist davor gefeit, dass so etwas eintritt. Besser man ist dafür gewappnet. Daher bat ich um Mithilfe zu dem eigentlichen Problem, nicht zur Backup-Strategie. ;)

Ich habe ein riesiges Problem. Zuerst die Vorgeschichte kompakt zusammengefasst: Einziger DC einer kleinen Domäne ist abgeraucht. NTDS- und SYSVOL-Ordner konnte noch gesichert werden bevor gar nichts ging. Sämtliche Versuche Verzeichnisdienst wiederherzustellen sind fehlgeschlagen. Sicherungen sind unvollständig, ASR nicht vorhanden. Also DC mit dem gleichen Namen aufgesetzt, DCPROMO durchgeführt (gleicher Domänenname), gesicherten NTDS- u. SYSVOL-Ordner übernommen und Option "Verzeichnisdineste wiederherstellen" ausgewählt. Nach einem Neustart komt nun die FM "Das angegebene Netzwerkkennwort ist falsch.", der Verzeichnisdienst startet nicht. Wie kann ich das Kennwort zurücksetzen? Hüülfe!! :-/ PS: Bitte keine Anregungen zum Thema Backup. Das ist mir schon klar. ;-) Letztlich schreibe ich, weil diese Situation so nunmal eingetreten ist.

So kompliziert wie das Problem so einfach die Lösung. Zum Auflösen via Windows Explorer wird ein Dienst benötigt: TCP/IP-NetBIOS-Hilfsprogramm. Ein kompletter Verzicht auf WINS und NetBIOS ist wohl nur theoretisch mit Win XP möglich. Schade.

Und ich verstehe nicht warum wir über indiskutable Auflösungssysteme reden. Es gibt DNS und das soll genutzt werden. Wenn ein NetBIOS-Name aufgelöst werden soll sendet Windows zuerst einen Broadcast bevor er den WINS kontaktiert. Also kein NetBIOS. Fakt ist, der Windows Explorer interpretiert den UNC falsch. Alle anderen Systeme arbeiten mit DNS. Wie bekomme ich es beim W. Explorer hin?