Jump to content

NilsK

Expert Member
  • Gesamte Inhalte

    17.511
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von NilsK

  1. Moin, Dann seid ihr der Service Provider, der den SPLA-Vertrag hält? Dann könnte es passen. Aus den bisherigen Angaben war ich nicht sicher, ob ihr der Kunde eines Hosters seid und selbst den Server per SPLA von diesem bekommt, um darauf dann Dienste für eure Kunden anzubieten. Das hätte nach meinem Verständnis nicht gepasst. Gruß, Nils
  2. Moin, Dann sollten wir vermutlich das Szenario, das hier genutzt werden soll, noch mal im Detail darstellen. Mir schwant, dass das ganze Konstrukt so nicht geht. Gruß, Nils
  3. NilsK

    Hyper-V VM startet nicht

    Moin, Ich kann mir nicht vorstellen, dass sich dazu nichts im Log findet. Wurden evtl. als letztes vor dem Phänomen Updates installiert? Die können schon mal Zeit brauchen. Gruß, Nils
  4. Moin, Ob das zu einem Server passt, den ihr selbst verwendet, ist mir nicht ganz klar, dazu kenne ich das Modell im Detail nicht genug. Ob sich SPLA mit einem External Connector verträgt, kann ich auch nicht sagen. Das sollte euer Disti euch aber beantworten können. Oder wir klingeln hier mal den @lizenzdoc an. Gruß, Nils
  5. Moin, Ihr selbst habt den Server per SPLA lizenziert? Oder wie? Das Szenario klingt für mich jedenfalls nach einer External Connector License. Gruß, Nils
  6. NilsK

    Hyper-V VM startet nicht

    Moin, Um Evgenijs Frage zu beantworten oder evtl. direkt Hinweise zur Problemlösung zu finden, kann es helfen, im Abgesicherten Modus ins Ereignisprotokoll zu schauen. Gruß, Nils
  7. Moin, Entschuldige, dass das so rüberkam. Ich wollte nichts mit "d**f" andeuten. Das war zu flapsig. Da hast du völlig Recht. Was ich meinte, ist der Punkt, dass es keine einfache Lösung gibt und du dir das sicher schon gedacht hast. Gruß, Nils
  8. Moin, In Azure halt noch weniger günstig. Wenn jemand schon gesagt hat, dass ein Golf ihm zu teuer ist, kann man ihm ja noch einen Cayenne vorschlagen. Gruß, Nils
  9. Moin, auf einer Kabarett-Bühne würde man jetzt sagen: "Merkste selber, ne?" Wenn es eine einfache und günstige Lösung gäbe, dann hättest du sie bereits. Es gibt aber keine. Es wird teuer, und es wird aufwändig. Das wird der Kunde akzeptieren müssen. Anderenfalls geht es nur so weiter wie jetzt, und das scheint ja nicht ausreichend zu sein. Für das, was wir hier von dem Szenario bislang wissen, dürfte einzig eine zentrale Datenhaltung mit ggf. dezentralem Zugriff in Frage kommen. Eine Synchronisation "möglichst in Echtzeit" (was vermutlich meint: ohne Verögerung; "Echtzeit" ist eigentlich was anderes) dürfte schon an den Datenmengen scheitern, die bei CAD zusammenkommen. CAD "per Citrix" wird nicht günstig, ist aber machbar. Gruß, Nils
  10. Moin, Ich tute in dasselbe Horn. Hier nicht mehr selbst basteln, sondern sich kompetent beraten lassen und ein tragfähiges Konzept bauen. Das ist nicht kompliziert und nicht teuer, aber wenn man sich nicht genügend auskennt, kriegt man es nicht hin. Auch nicht mit Support aus einem Forum. Gruß, Nils
  11. Moin, Die Frage ist aber noch offen, ob du überhaupt ein AD brauchen würdest. Um genauer zu antworten, fehlen uns Informationen, was denn die Anforderungen sind. Gruß, Nils
  12. Moin, das war genau der Hintergrund meiner Frage. Sind wir uns ja mal einig. Gruß, Nils
  13. Moin, Was soll denn der Server machen? Nur "Netzlaufwerke" anbieten, also als Dateiserver arbeiten? Oder noch was anderes? Gruß, Nils
  14. Moin, Ja, und eigentlich ging es nur um einen Hinweis, damit man sich hinterher nicht über seltsame Ergebnisse wundert. Rein technisch spricht nichts dagegen. Nur um das noch mal zu betonen. Gruß, Nils
  15. Moin, Ich habe das bei verschiedenen Applikationen gesehen, die mit IdM-Hintergrund die Namens- und Adressdaten des AD auswerten und verwenden. Wenn die aus den USA kommen, nehmen die das Initial mit in den Namen einer Person auf, weil das dort üblich ist. Hier ist das völlig unüblich (und im ADUC-GUI auch noch falsch übersetzt), daher wundert man sich dann oft, was dabei rauskommt. Gruß, Nils
  16. Moin, Die Frage ist ja auch, ob es vor dem Hintergrund, den Evgenij meint, einen Unterschied macht, ob man nach 120 oder nach 365 Tagen das Kennwort ändert. Soweit ich es verstehe, müsste man das dann schon in wesentlich geringeren Abständen tun, eher unterhalb von 24 Stunden. Also braucht man zusätzliche Sicherungen, denn das ist ja nicht praktikabel. Es zeigt eher, dass das ganze Kennwort-Ding M*st ist. Eine Lösung habe ich nicht dafür, aber der NTLM-Einwand zielt auf eine andere Ebene als das hier diskutiere Thema. Gruß, Nils
  17. Moin, Ich möchte bei der Gelegenheit aber darauf hinweisen, dass man zwar durchaus "brachliegende" AD-Felder umnutzen kann, dabei aber Nebenwirkungen auftreten können. Das Feld "Initials" gehört zu denen, die hier und da von Anwendungen ausgewertet werden, daher würde ich da nicht "irgendwas" reinschreiben. Gruß, Nils
  18. Moin, Bei solchen Performance-Fragen muss man auch schauen, ob es um sehr dicht gepackte Enterprise-Umgebungen geht - da können sich solche Effekte so summieren, dass man vielleicht Auswirkungen bemerkt - oder um eine "typische" mittelständische Umgebung, wo man normalerweise überdimensionierte Systeme hat (oder man hat altes Zeug, das ohnehin schon aus Löchern pfeift, aber dann kommt es auch nicht mehr darauf an). Es ist jedenfalls, wie du selbst schon sagst, unwahrscheinlich, dass das eine Einschränkung darstellt. Und wenn, dann wäre das kein Grund, auf die Sicherheit zu verzichten. Gruß, Nils
  19. Moin, Haben denn deine Nachforschungen etwas ergeben? Wir müssen ja nicht nach einem Mauseloch suchen, wenn es die Maus gar nicht gibt. Vermutlich sollte man da noch etwas abwarten wegen der Feiertage. Wenn es etwas Naheliegendes gäbe, wäre es erfahrungsgemäß hier schon genannt worden. Gruß, Nils
  20. Moin, Ah, sehr gut. Danke für die Rückmeldung! Gruß, Nils
  21. Moin, Keine Ahnung, aber du schriebst von Sekunden, und das sollte man per Timing doch hinkriegen. Muss ich ja aber auch nicht lösen. Gruß, Nils
  22. Moin, Ja, schon, aber der Witz bei den Quest-Tools ist ja gerade, dass sie das leisten, was man von den Bordmitteln erwartet, aber nicht bekommt. Da wundert es mich dann immer wieder, dass sie selbst solche Lücken lassen. Zumal es für Quest, wenn ich es richtig verstanden habe, recht einfach sein müsste, das Problem zu umschiffen. Das Timing verändern oder mit ein paar Zeilen Code den richtigen DC ausfindig machen, dürfte ja so schwer nicht sein. Gruß, Nils
  23. Moin, Klingt plausibel. Also, eigentlich klingt das total beh*mmert, aber wenn man schon seit fast 25 Jahren Automatisierung von AD-Prozessen beobachtet, dann ist es eben plausibel. Nebenbei willst du uns aber sagen, dass das Quest-Tool diese Probleme nicht selbst behandelt, ja? Auch das würde ich in Verbindung mit dem Hersteller nicht zum ersten Mal hören. Was hatten wir vor 15 Jahren für einen Aufwand, hinter den Lücken im Migrator herzuscripten. (Aber das nur am Rande.) Danke für den Einblick. Gruß, Nils
  24. Moin, Ich gehe davon aus, dass das nicht der Punkt ist, auf den ein Auditor sehr viel Zeit verwenden würde. Da gibt es für ihn anderswo mehr zu holen. Interessanter Punkt aber auf jeden Fall. Und guter Hinweis, dass die Angaben dort auch nicht eindeutig sind. Gruß, Nils
  25. Moin, Hmm, so habe ich das noch nie gehört. Klingt fast wie eine Frage für den @lizenzdoc. Gruß, Nils
×
×
  • Neu erstellen...