NilsK

Moin, ja, in der Tat. Wir hatten mal den Fall, dass wir aufgrund der Niemals-doppelte-SIDs-Annahme ein paar Kundenumgebungen überprüft haben. Wir sind dann ganz bleich geworden, als ausgerechnet die DCs immer dieselben SIDs hatten. Kurze Zeit später haben wir dann herausgefunden, dass die DCs einer Domäne immer denselben SID haben. Gruß, Nils

Moin, Testclient?! Quatsch. Hab ich nicht mitgedacht. Gruß, Nils

Moin, was für eine Fehlermeldung bekommst du denn? Anders als oft vermutet wird, verursachen doppelte SIDs gerade beim Domänen-Join eigentlich keine Probleme. Vielleicht liegt noch was anderes im Argen. [Eindeutige Computer-SIDs unwichtig? | faq-o-matic.net] https://www.faq-o-matic.net/2009/11/17/eindeutige-computer-sids-unwichtig/ Gruß, Nils

Moin, nö, das ist so schon Best Practice. [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] https://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Das wäre auch mein Tipp. Gruß, Nils

Moin, jaja, die Hochschulen. Viele davon immer noch ein Hort der begründungsfreien Abneigung gegen Windows, auch nach fast 20 Jahren AD. Das Lustige dabei: Als Beleg für ihre Abneigung führen Uni-Admins gern die vielen Probleme an, die Windows angeblich verursacht - die sie aber gar nicht hätten, wenn sie zwei, drei Dinge in ihrem Verfahren ändern und es einfach richtig machen würden. Also: Es spricht nichts dagegen, das DNS zentral laufen zu lassen, nur müssen sie dich dann zwingend bei den Erweiterungen unterstützen. Das sind nur wenige Einträge, aber die müssen sie halt machen. Gruß, Nils

Moin, man kann das AD durchaus mit einem Unix-DNS installieren und betreiben, aber dafür ist direkte Zusammenarbeit mit den DNS-Administratoren nötig. Die DNS-Einträge müssen natürlich korrekt und vollständig vorhanden sein. Noch sinnvoller ist, in dem Unix-DNS dynamisches DNS einzurichten. Oder, was meist die beste Variante ist: Für das AD gibt es eine eigene DNS-Zone, die von den DCs selbst gehostet wird. Für die allgemeine Namensauflösung gibt es dann einen Forwarder auf das Unix-DNS. Und im Unix-DNS richtet man eine Delegation (oder auch ein Forwarding) für die AD-DNS-Zone ein, die auf die DCs zeigt. Es bleibt aber dabei, dass man mit den DNS-Admins zusammenarbeiten muss. Gruß, Nils

Moin, mit einem anderen Domänenadmin das Kennwort zurücksetzen. Das Phänomen mit "Als Admin ausführen" und "runas" ist normal, denn seit Windows 8 (? vielleicht auch schon früher) kann man per runas keine Adminrechte mehr anfordern. Gruß, Nils

Moin, zur Abwechslung könntest du ja mal anfangen, dich mit den Antworten zu beschäftigen, die dir hier gegeben werden. Die vorgeschlagene Lösung geht auf praktisch alle deine Punkte ein. Manuell einrichten und "installieren" musst du praktisch nichts. Mir ist es am Ende egal, aber es macht einfach wenig Spaß, wenn man Vorschläge macht und nur auf unbegründete Ablehnung stößt. Gruß, Nils

Moin, Das ist ja oft so. ;) Gruß, Nils

Moin, Thin clients und RemoteApps. Gruß, Nils

Moin, also ... das wichtigste wäre ja zu klären, was man in welcher Situation in welcher Qualität wiederherstellen muss. Die Überlegungen ausgerechnet beim Gerät zu beginnen, ist ein komplett falscher Ansatz. Ja, ich wiederhole mich. Gruß, Nils

Moin, Dir scheint nicht ganz klar zu sein, wer da überhaupt die Zertifikate prüft, oder? Wenn, dann musst du den Cache auf dem Gateway löschen, nicht auf einem Client oder dem DC. Den Online-Responder installiert man auf der CA (in sehr kleinen Umgebungen) oder separat, jedenfalls wird er in die CA eingebunden. Ob dein Gateway damit umgehen kann, ist damit aber noch nicht gesagt. Vielleicht solltest du dich mal an den Hersteller deiner VPN-Lösung wenden, welche auch immer das ist. Gruß, Nils

Mein, Technisch sehe ich das auch so. Gruß, Nils

Moin, Klingt für mich verdammt oberflächlich, aber das musst du selbst wissen. Gruß, Nils

Moin, kann denn das VPN-Gateway auf mindestens einen aktuellen CRL-Pfad zugreifen? Tut es das auch? Steht der Pfad, auf den das Gateway zugreifen kann, in der Liste vorne? Da kann es z.B. zu Timeouts kommen. Kann das Gateway mit Delta-CRLs umgehen? Sind wirklich alle Speicherorte aktualisiert? Wie gesagt, dort muss man sie manuell oder per Skript hinkopieren, die Aktualisierung selbst betrifft nur die "Hauptkopie", aber nicht die anderen Pfade. Gruß, Nils

Moin, wieso kannst du das mit RemoteApp dann vergessen? Ganz im Gegenteil würde ich es eher so sehen, dass das genau dein Ansatz wäre. Soweit ich weiß, lassen sich die auch mit Thin Clients verwenden. Gruß, Nils

Moin, tjaja, an der Stelle können sich so manche Tücken verbergen, die systemimmanent sind. Zunächst mal gehe ich davon aus, dass wir hier über Clientzertifikate reden, also der Client präsentiert ein Zertifikat, mit dem er sich dem VPN-Gateway gegenüber ausweist. In dem Moment muss nicht der Client auf die Sperrliste zugreifen, sondern das VPN-Gateway. Ist gewährleistet, dass dies funktioniert? Sind die Sperrlisten an allen Downloadpfaden aktuell, die im Zertifikat angeben sind? Üblicherweise muss man die manuell oder über einen separaten Prozess dorthin kopieren, das reine Aktualisieren reicht nicht aus. Dann kann es durchaus sein, dass der Client für die Anmeldung gar nicht das Zertifikat präsentiert, sondern ein separates Cookie (oder was in der Art), um den Prozess zu vereinfachen. Dann hängt es von der Lebensdauer des Cookies ab, wie lange er zugreifen kann. Sowas müsste sich in der Konfig des VPN-Gateways steuern lassen. Das nur als zwei Ansätze, über die ich schon gestolpert bin. Gruß, Nils

Moin, fangen wir doch noch mal von vorne an: Was genau willst du denn insgesamt erreichen? Es ist meist für uns wenig sinnvoll, auf Detailfragen einzugehen, wenn wir den Hintergrund nicht kennen. Gruß, Nils PS. Wo hast du den Schritt 1 denn her? Das ist bei Windows Server 2012 R2 gar nicht mehr aktuell ...

Moin, was du bislang beschreibst, klingt für den bisherigen Einrichtungsstand völlig normal. Du lässt die User auf den vollen Desktop zugreifen, damit können sie (natürlich) alle Programme und Daten nutzen, die es auf dem Terminalserver gibt. Eine Einscchränkung auf bestimmte Programme bekommt man beim Desktopzugriff ohne Drittanbietersoftware (oder erhebliche Klimmzüge) nicht hin. Du könntest dir allerdings RemoteApps ansehen, die wären für deine Idee wohl besser geeignet - dort gibst du einzelne Applikationen frei, die dem User dann in seinen lokalen Client-Desktop eingeblendet werden. "Dieses Kachelzeugs" hättest du mit Windows 2012 oder R2. Mit Windows 2016 sähe das schon wieder anders aus. Remotezugriff ist nicht ganz ohne, nimm dir nicht zu viel vor. Das muss vor allem ordentlich abgesichert sein. Dazu schaust du dir das RDS Gateway an. Für Testzwecke benötigst du keine RDS-CALs. Für 90 oder 180 Tage (hab ich grad nicht im Kopf) geht es ohne. Gruß, Nils

Moin, das Gerät (da ist dann wohl quasi das Chassis bzw. der Controller gemeint) kann bis zu 60.000 IOPS bedienen, sofern die Platten so viel liefern. Das würden sie in deinem Szenario aber nicht tun. MPIO bringt Ausfallsicherheit, aber keine Performancesteigerung. Welche Performance brauchst du denn? Du musst davon ausgehen, was deine VMs bzw. die Applikationen in Summe benötigen. Danach weißt du, was du anschaffen musst. Gruß, Nils

Moin, du willst uns jetzt aber nicht sagen, dass derselbe defekte Server nach so vielen Tagen immer noch unverändert und ohne Redundanz läuft?! Mutig ... dann wünsche ich ein entspanntes Wochenende. Gruß, Nils

Moin, und noch mal genau prüfen, ob ihr wirklich Roaming Profiles braucht. Das ist eine erhebliche Fehlerquelle, die bei einem Betrieb mit mehreren Standorten noch schlimmer wird. Profile würde ich niemals über das WAN ansprechen, egal ob Hauptstandort, RZ oder Cloud. Erspart euch das lieber. Gruß, Nils

Moin, ich rate von einer Datenverteilung ab. Entweder ein gemeinsamer Cloudspeicher oder die Daten an einem Standort halten und den Zugriff vom zweiten Standort aus per Terminalserver realisieren. Gruß, Nils

Moin, ich weiß nicht, wie es bei dem HPE-Modell ist, aber bei professionellen Storage-Systemen ist es oft so, dass nur Originalplatten unterstützt werden und andere oft auch nicht funktionieren (angepasste Firmware). Gruß, Nils

Moin, hm, ja, da könntest du Recht haben. ;) Geht ein wenig hin und her in diesem Thread. Vielleicht sollte der TO noch mal sortieren. Ich würde momentan noch nicht mal davon ausgehen, dass es überhaupt die IOPS sind. Ich hätte zunächst den Code der Applikation und die Organisation der Datenbank im Verdacht. Gruß, Nils