NilsK

Moin, Holzweg. "Kennwort läuft nie ab" heißt genau das und hat nichts mit Sperrungen zu tun. Kennwortrichtlinien kann man nicht auf OU-Ebene definieren. Drei Versuche sind viel zu wenig. Wenn man es schon macht, dann mindestens 20 Versuche. Ernsthaft. Siehe Jans Link. Besser als Sperren sind immer komplexe Kennwörter, mindestens für Admin- und Dienstkonten. Wenn überhaupt, dann mit Fine-Grained Password Policies, siehe Zahnis Link. Gruß, Nils

Moin, naja, müsste man sich mal ansehen. :D Gemäß üblichen Troubleshooting-Vorgehensweisen würde ich jetzt mal Eventlogs durchsehen. Dann würde ich mir die tatsächliche Konfiguration der CA mal ansehen. Auch würde ich schauen, ob denn überhaupt Zertifikatsvorlagen eingerichtet und passend berechtigt sind. Dass sie vorhanden sind, heißt ja noch nicht, dass sie auch bereitgestellt sind. Wenn ich so nicht weiterkäme, würde ich mir jemanden suchen, der sich mit der Windows-CA auskennt. Da sich die Komponente leider seit Windows 2000 kaum weiterentwickelt hat, ist sie nicht ganz selbsterklärend, man muss schon einiges dazu wissen. Und ernsthaft: Wenn man eine PKI einrichtet, ist das eine Sicherheitskomponente. Sowas würde ich nicht nur mit Forensupport machen. Gruß, Nils

Moin, was sagt dcdiag /E? Was sagen die Eventlogs der beteiligten Server? Ändert sich was, wenn du die beiden Server nacheinander mit Wartezeit neu startest? Namensauflösung prüft man nicht mit nslookup, sondern am einfachsten per ping. Gibt es dabei Auffälligkeiten? Prüfe noch mal ipconfig /all auf beiden Servern die tatsächliche Konfiguration. Hat einer der Server mehrere Netzwerkkarten? Ist evtl. die Netzwerkkarte nach der Erstinstallation getauscht worden? Handelt es sich um Hardware oder VMs? Ist einer der Server aus einem bestehenden Image geklont worden? Gruß, Nils

Moin, die Frage ist berechtigt. Das Thema solltet ihr mit dem Anbieter noch mal klären. Grundsätzlich ist es bei den meisten SaaS-Anbietern, die eine Authentifizierung per SAML (also ADFS) anbieten, durchaus so, dass der Anbieter lokal in seiner Applikation Konten benötigt, um die einzelnen User auseinanderzuhalten. Manchmal wird das auch anders gelöst (anhand der Daten im SAML-Token), aber das Verfahren mit lokalen Konten ist üblich. Was hingegen unüblich ist und was du zu Recht kritisierst, ist der direkte Zugriff auf das AD, um die Konten abzugleichen. Das ist, wenn es tatsächlich so gefordert wird, natürlich ein No-Go. Die meisten Anbieter arbeiten hier mit regelmäßigen Imports, die man z.B. per CSV regelmäßig zur Verfügung stellt. Varianten davon wären andere Importformate (etwa bei Azure/Office 365). In dem Fall benötigt der Anbieter aber natürlich nur wenige Rahmendaten zu den Usern (meist nur Name und Mailadresse, um die User eindeutig auseinanderzuhalten). Das funktioniert meist auch sehr gut, denn im Regelfall reicht es aus, neue User zügig übertragen zu haben. Ausgeschiedene User muss man nicht sofort beim Anbieter löschen, weil man die Anmeldung ja selbst über die ADFS-Regeln verhindern kann. Hier solltet ihr also auf jeden Fall noch mal mit dem Anbieter besprechen, welche Importmöglichkeiten er vorsieht. Gruß, Nils

Moin, ah, OK, danke für die Rückmeldung. Ja, bei solchen Systemen sorgen die Management-Komponenten schon mal für unangenehme Überraschungen. Denkt man nicht immer dran, sollte man aber immer als Verdächtigen im Blick haben. Gruß, Nils

Moin, "klappt nicht" heißt genau was? Um einzugrenzen, ob das Problem in der VM-Konfiguration oder im VM-Betriebssystem liegt, könntest du die virtuellen Platten (bei abgeschalteter VM) testhalber an eine andere Stelle kopieren und sie dann an eine neue VM anbinden. Wenn die Netzwerkkarten dann auch nicht funklionieren. liegt es sehr wars***einlich am VM-Betriebssystem. Dann wäre das Eventlog usw. zu konsultieren. Wenn es nichts hilt, ein VM-Backup wiederherstellen. Gruß, Nils

Moin, versuch mal, eine neue Netzwerkkarte hinzuzufügen und die vorhandene erst mal innerhalb der VM zu deaktivieren. Geht es damit? Gruß, Nils

Moin, dann lies noch mal, was ich geschrieben habe. :D Gruß, Nils

Moin, da wirst du die Domänenanbindung neu machen müssen. Da Macs keine Windows-Rechner sind, haben sie eine eigene Implementierung eines AD-Clients. Gruß, Nils

Moin, ja, okay, etwas simplifiziert. :D Was ich meine: Azure Stack ist nicht zum Testen gedacht wie eine Eval-Version von Exchange. Das missverstehen viele, wenn nicht die meisten. Und mir scheint, dass das auch hier das Missverständnis ist. Gruß, Nils

Moin, ah. OK, da kann man von außen lange suchen. ;) Ja, die Offline Folders sind ein steter Quell der Freude. Leider alles andere als zuverlässig. Danke für die Rückmeldung. Gruß, Nils

Moin, ja, natürlich. Wenn es um das Nutzen von Azure geht, ist das die nächstliegende und produktivste Variante. Azure Stack ist ja keine vollständige Implementierung - alle Services usw. müsstest du da selbst bauen. Das ist ein Produkt, das sich an Hoster richtet. Gruß, Nils

Moin, und was soll das Ganze? Warum nicht Azure-Testaccounts und direkt mit dem loslegen, worum es wirklich geht? Gruß, Nils

Moin, also, "schwere Kost" ist jetzt schon sehr zurückhaltend. Eine Azure-Stack-Implementierung braucht normalerweise eine ganze Palette an Hardware (und ich meine jetzt keine Tetrapack-Palette, sondern eher das Euroformat). Und entsprechend viel Zeit. Wenn du beides hast - okay. Aber für mich klingt das jetzt gerade nach Holzweg. Gruß, Nils

Moin, oh, da hast du dir ja was vorgenommen. Was ist denn das Ziel der Aktion? Gruß, Nils

Moin, gern. Gruß, Nils

Moin, ich würde mit dem Kunden über seine Anforderungen reden und ihn aus Sicht seiner Geschäftsprozesse (!) durch den Design-Prozess für ein Recovery-Konzept führen. Daraus würde ich dann die nötige Backup-Strategie ausarbeiten. Alles andere würde das Pferd von hinten aufzäumen. Die genannte Anforderung mag ein erster Anfang sein, reicht aber offenkundig nicht aus. Gruß, Nils

Moin, prüfe vor allem, ob VMQ abgeschaltet ist. Möglicherweise auf einem Host ja, auf dem anderen nicht. Wenn das der Fall ist, schalte es auf beiden Seiten mal ab und prüfe, ob das was ändert. Gruß, Nils

Moin, gut, um noch mal kurz bei diesem USB-Stick-Mythos zu bleiben: Es handelt sich um SATA-DOMs, wenn es supported sein soll. Technisch schon verwandt mit einem USB-Stick, aber eben doch anders. Und teurer. Und zwar so viel teurer als ein USB-Stick, dass ein kleines RAID-1 mit einem Onboard-Controller preislich nun wirklich keinen relevanten Unterschied macht. Und zur Installation: Ja, gut, vielleicht kann man einen ESXi in 15 Minuten installieren. Eine gut vorbereitete Hyper-V-Installation dauert eine Stunde, wobei der größte Zeitanteil das Kopieren von Dateien ist. Auch nicht ernsthaft ein Unterschied, der irgendwas ausmacht. Bulk-Installationen vorzubereiten, ist in beiden Welten ein vergleichbarer Aufwand. Es gab in der vSphere-Welt einige Kunden, die das ganz toll fanden, aber ich treffe sehr selten welche an, die das noch ein zweites Mal machen. Wir sind jetzt hier aber etwas vom Thema weg ... Gruß, Nils

Moin, ich würde Folgendes machen: per Logonskript alle hosts-Dateien einsammeln und auf einem Share ablegen die Dateien auswerten, welche Einträge benötigt werden die benötigten Einträge ins DNS übernehmen die hosts-Dateien per Startup-Skript löschen bzw. durch die Windows-Standarddatei ersetzen Das kann man in ein, zwei Tagen fertig haben. Ich würde das auch priorisieren, weil hosts-Dateien eine 1a-Fehlerquelle sind. Gruß, Nils

Moin, wie gesagt - in Wirklichkeit ist es bei ESXi ja auch kein USB-Stick, weil die viel zu wenig zuverlässig sind. Und in der Praxis trifft man sowas auch praktisch nie an. Gruß, Nils

Moin, nimm es uns nicht übel - aber genau das ist die Sorte Grundlagen, die ein Forum nicht vermitteln kann. Auch wenn es hier gewissermaßen um "fortgeschrittene Grundlagen" geht. Wie du ein Backup wiederherstellen musst, hängt von der ganz konkreten Situation ab. Was willst du wiederherstellen, in welchem Zustand ist der Server, wie hast du gesichert ... SQL Server bzw. das Management Studio können dir vorschlagen, was du wiederherstellen könntest, wenn sie Zugriff auf de Sicherungsverlauf haben. Im Fall eines Server-Recoverys haben sie das nicht, da musst du dann also selbst wissen, was du tun musst. Wenn du gar nicht alles wiederherstellen musst, sondern einen bestimmten historischen Stand brauchst, dann nützt dir der Vorschlag des SSMS auch nichts. Es empfiehlt sich - wie eigentlich immer bei der Recovery-Planung - die nötigen Schritte vorzuplanen und zu üben. Dabei kann man dann auch wertvolle Hinweise erhalten, mit denen man z.B. ein Skript aufbauen kann, das Dinge vereinfacht und Fehler vermeidet. Gruß, Nils

Moin, Eine Transaktions-genaue Wiederherstellung geht so nicht. Wenn du genau weißt, wann die Transaktion stattgefunden hat, kannst du den Zeitpunkt auswählen. Die genaue Transaktionsnummer lässt sich ja ohnehin nicht herausfinden. Was du dann in welcher Reihenfolge wiederherstellen musst, ergibt sich aus dem Backup-Verfahren. Das kann man dann auch scripten. Gruß, Nils

Moin, Den Hypervisor auf einen Stick zu installieren, ist in Wirklichkeit auch mit VMware nicht supported. Dort geht es um SATA-DOMs, also eine Art SSD. Ein echter Vorteil ist das nicht. Die typische Installation für das System ist ein kleines RAID-1. Und natürlich ist Hyper-V auch für große Cluster-Installationen geeignet. Gruß, Nils

Moin, es gibt viele Wege, die nach Rom führen, aber den halte ich für ziemlich abwegig. Nichts gegen "Frankys Web", der manchmal gute Beiträge hat - aber wer zur Überwachung der Exchange-Volumes den File Server Resource Manager installiert, ist ziemlich auf dem Holzweg. Das ist wie mit dem Auto zur Straßenecke fahren, die 20 Meter entfernt ist. Gruß, Nils