Jump to content

NilsK

Expert Member
  • Gesamte Inhalte

    17.621
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von NilsK

  1. Moin,

     

    OK, das sind alles Gründe, die zusammen durchaus für einen zentralen Ansatz sprechen können. Sehr wahrscheinlich ist VDI aber eher nicht das richtige, sondern tatsächlich eine "klassische" RDS-Umgebung, alias "Terminalserver". VDI hat nur selten wirklich Vorteile, fügt aber einige Nachteile, Umstände und Kosten hinzu.

     

    Lass dich dazu auf jeden Fall kompetent beraten. Es gibt eine Reihe Stolperstellen, die man durch gute Planung (basierend auf Erfahrung) vermeiden kann. Das Know-how von Null aufzubauen, ist sehr aufwändig (und führt zu vermeidbaren Irrtümern; z.B. deutet deine Skizze oben auf Missverständnisse hin).

     

    Gruß, Nils

     

  2. Moin,

     

    nein, Office dürfte an der Stelle nicht zu den Sonderfällen gehören. Gemeint ist hier sowas wie Firefox oder Thunderbird, die nicht den Zertifikats-Store des Betriebssystems verwenden. Dann würde es aber weder per GPO noch "manuell" gehen, sondern man müsste das Zertifikat eben innerhalb der Applikation einbinden.

     

    Auf die Schnelle kann ich auch grad nicht sagen, woran es scheitert. Nur ein Detail noch: Ein Zertifikat wird nicht dadurch ein Root-Zertifikat, dass es im Store an einer bestimmten Stelle liegt. Ein Root-Zertifikat ist von selbst ein solches, weil es von keinem anderen Zertifikat abgeleitet ist. Das kannst du dir in den Eigenschaften des Zertifikats im Register "Zertifizierungspfad" ansehen.

     

    Gruß, Nils

     

  3. Moin,

     

    ein Zertifikat "verhält" sich nicht, weil es kein aktiver Code ist. 

     

    Typischerweise liegen solche Phänomene daran, dass der automatische Import des Zertifikats nicht korrekt war. Du sprichst davon, dass du es als Stammzertifikat importierst. Ist es wirklich ein solches oder ist es ein abgeleitetes Zertifikat? Beim manuellen Import ist es oft so, dass man "stillschweigend" die ganze Zertifikatskette importiert, was beim GPO-Import so nicht der Fall ist.

     

    Gruß, Nils

     

  4. Moin,

     

    Es spricht erst mal überhaupt nichts dagegen, das Schema des AD zu erweitern. Das ist nichts Schlimmes, sondern seit über 20 Jahren so vorgesehen. Eine Anwendung, die mit den AD arbeiten wiil, bekommt man hingegen nur selten auf AD LDS umgebogen.

     

    Wenn du uns verrätst, um welche Anwendung es geht, können wir vielleicht konkret was dazu sagen.

     

    Gruß, Nils

    PS deine Vermutung über AD LDS trifft so übrigens nicht zu.

  5. Moin,

     

    ist die Netzwerkkarte wirklich "verschwunden"? Oder kannst du sie nur nicht über den beschriebenen Weg anzeigen? Hängt der ganze Server oder ist es nur das GUI (also am Ende der Explorer), das dann nicht geht?

     

    Anders gefragt: Äußert sich das Problem schon, bevor du versuchst, die Netzwerkkarte im GUI anzuzeigen? Wie äußert es sich? Kannst du in solchen Situationen über CMD oder PowerShell die Netzwerkeigenschaften anzeigen?

     

    Sind auf dem Host nur die zwei VMs, die du erwähnst, oder noch andere? Falls wirklich nur die eine VM das Problem zeigt, spricht das eher gegen Norberts Idee, schließt sie aber noch nicht aus.

     

    Gruß, Nils

     

  6. Moin,

     

    Warum fängst du denn ausgerechnet mit einer eher komplexen Aufgabe wie dieser an?

     

    Ich würde das in mindestens zwei Teile trennen und mir diese zunächst separat aneignen: die CSV auswerten und einen AD-User manipulieren. In den CSV-Schritt kannst du dann ausprobieren, wie du mit diesen speziellen Werten umgehst, ohne dass es jedes Mal Fehler im AD gibt.

     

    Gruß, Nils

     

  7. Moin,

     

    Wenn du eine "Gruppe" pro DeviceId haben willst, musst du dir Gruppierung so definieren, dass es in anderen Feldern keine Unterschiede gibt. Die Gruppe wird in SQL nur dann gebildet, wenn alle betrachteten Werte gleich sind.

     

    (Das dürfte in etwa das sein, was auch MDD meint.)

     

    Bekommst du also pro ID mehrere Zeilen, dann werden die sich irgendwo unterscheiden.

     

    Es gibt dabei auch oft mehr als einen Weg. Hier dürfte auch ein Sub-Select als Lösungsansatz in Frage kommen. Ein Select könnte dabei nur die DeviceId und das Datum rausfinden, der andere mit diesen Ergebnissen den Rest. Das kann sich in großen Datenbanken auch in der Performance dramatisch unterscheiden, aber vielleicht kommt es darauf hier gar nicht an.

     

    Gruß, Nils

     

  8. Moin,

     

    ja, ich danke auch - allerdings sind die Ergebnisse nicht ohne Weiteres auf das eigentliche Szenario übertragbar. Es fehlen die große Node-Anzahl mit gleicher Verteilung und das Quorum.

     

    Was sich aber wohl bestätigt hat: Wenn man sich im "Grenzbereich" auf so ein Konstrukt verlassen können will, braucht man Prozesse drumrum.

     

    Gruß, Nils

     

×
×
  • Neu erstellen...