NilsK

Moin,

Ja, ich wusste auch, dass Martin sich nicht zurückhalten kann. Und dass wir ihn (bzw. alle anderen Lesenden dieses Threads) dann darauf hinweisen müssen, dass seine AD-Umgebung mit weitem Abstand ein Ausreißer ist. 

Martin weiß so gut wie wir, dass jemand, dessen Umgebung so groß ist, die hier diskutierten Fragen gar nicht stellen würde, weil er über Personal und Prozesse verfügt, die das unnötig machen. Anderen hier ist das möglicherweise nicht bewusst, daher weisen wir gern erneut darauf hin. 

Und natürlich weiß Martin auch, dass ein DC mit 16 GB auch in so einer großen Umgebung nicht derart langsam sein würde wie beschrieben, sodass der Kern meiner Aussage eben doch zutrifft. Auch hier sei das aber für alle anderen noch mal erwähnt.

Gruß, Nils

Moin, 

Ein DC braucht weder viel RAM noch viel CPU. Wenn das also was lahm ist, dann ist das ein deutliches Zeichen, dass irgendwas aus dem Lot ist. 

Gruß, Nils

Moin,

Evtl. falsche Einträge im DNS-Cache auf dem Server oder im Resolver-Cache auf dem Client. Außerdem machen, wenn ich es richtig verstanden habe, mache Browser die DNS-Auflösung selbst, da könnte es also auch falsche Daten im Cache geben.

Gruß, Nils 

Moin,

Am 21.4.2024 um 21:42 schrieb Scotx:

Der Server hat bei uns keine großen Aufgaben - ein SQL Express Server läuft dort drauf, Fileserver und Backup. Ansonsten hat der nichts zu tun...

dann würde ich darüber nachdenken, ihn abzuschaffen und durch Cloud-Dienste zu ersetzen.

Gruß, Nils

Moin,

man definiere "Mittelstand" ... aber gerade da stellt man oft fest, dass die Aufregung wegen der VMware-Lizenzen nicht gerechtfertigt ist. Wir betreuen eher kleine VMware-Umgebungen, da gibt es nicht nur keinen Exodus, sondern auch keine ernsthafte Aufregung. Und so mancher Enterprise-Plus-Kunde stellt jetzt fest, dass er die teuren Funktionen in Wirklichkeit noch nie gebraucht hat. Insofern sind wir als Dienstleister da ziemlich entspannt, hätten aber auch gleich mehrere Alternativen, wenn sie nötig wären.

Was Cloud-Projekte angeht - auch da definiere man "Mittelstand". Was eher vorbei ist, ist blindes "Lift-and-Shift", was in Wirklichkeit darauf hinauslief, VMs übertrieben teuer bei Azure laufen zu lassen. Migrationen nach SaaS gibt es vorrangig da, wo es bewährte und einfache Use Cases gibt. Da berät dann aber auch eher der SaaS-Anbieter als der Infrastruktur- oder Cloud-Dienstleister. Services neu entwickeln, das findet schon seit Jahren viel eher in der Cloud statt als auf eigener Hardware, aber das ist dann auch selten ein Mittelstandsthema.

Gruß, Nils

Moin,

prima, danke für das Feedback.

Gruß, Nils

Moin,

vor 18 Stunden schrieb daabm:

Da brauchst nicht mal Skript, das geht mit Zielgruppenadressierung auch direkt per GPP Environment aus den AD-Attributen

das war das, was ich mit meinem Vorschlag meinte, dem du widersprochen hast. Und wer bin ich, dass ich dann beharre ...

Gruß, Nils

Moin,

vor 2 Stunden schrieb Neopolis:

Darf ich mal eine Frage stellen? Was hängt ihr euch eigentlich so an der Postfachgröße auf?

weil das deine Formulierung am Anfang war:

Am 16.4.2024 um 20:27 schrieb Neopolis:

ich habe ein großes Postfach bei uns und teste jetzt seit ein paar Tagen Outlook Duplikates Remover 5.2.

Du bist dann mehrfach gefragt worden, was denn eigentlich das zu lösende Problem sei. Dass die Mailbox aufgrund der Duplikate für den User nicht gut nutzbar ist, hast du erst viel später gesagt. Also haben wir zunächst vermutet, dass du das Größenproblem zu lösen versuchst.

Daher wäre es nett, wenn du einfach mal ein bisschen weniger robust auftrittst. Wir wollten dir nämlich tatsächlich helfen.

Gruß, Nils

Moin, 

Wenn man denn tatsächlich die Umgebungsvariable bräuchte, wäre das ja trotzdem lösbar. So exotisch wird der Wert ja nicht sein, dass man ihn nicht mit etwas Skriptlogik rekonstruieren könnte.

Gruß, Nils

Moin,

und:

vor 2 Stunden schrieb testperson:

Die User müssen sich nach der Gruppenaufnahme ab- und anmelden

Gruß, Nils

Moin,

und was ist das Problem, das du zu lösen versuchst? Wie die anderen schon sagen, sind große Mailboxen schon lange nicht mehr per se ein Problem.

Gruß, Nils

Moin,

dann nimm nur die GPO-Variante und mach den Rest halt selbst über ein Skript: Ordner anlegen, Berechtigung setzen usw. Die Umgebungsvariable könnte per GPP oder per Logonskript gesetzt werden.

Mir wäre das viel zu viel Aufwand und Fehlerquelle für eine Kosmetik, die ein normaler User ohnehin nicht wahrnimmt, aber das muss ich ja nicht entscheiden.

Gruß, Nils

Moin, 

Ja, die Anforderung als solche ist nachvollziehbar und auch nicht exotisch. Die Umsetzung ist aber, wie wir ja schon andeuteten, falsch. 

Das sollte man korrigieren. Wird auch nicht wild sein, aber man sollte es jetzt schon koordiniert tun. 

Gruß, Nils

Moin,

was Jan sagt. Aber schon mal vorab als Einschätzung: So, wie ihr das gemacht habt, geht das nicht.

Gruß, Nils

Moin,

das bewirkt zweierlei: Fragt man den Computer nach seinem Hostnamen, dann gibt er sich als Teil der Domäne aus, die durch das Präfix angegeben wird. Und versucht der Computer selbst eine DNS-Namensauflösung, dann fragt er zuerst nach der Präfix-Domäne.

Was ist denn der Grund für deine Frage?

Gruß, Nils

Moin, 

Aber du brauchst doch kein Okta, um für 50-100 User OwnCloud bereitzustellen.

Gruß, Nils

Moin,

vor 43 Minuten schrieb sheppard81:

Letztendlich soll das ganze verwaltbar und kostengünstig bleiben

du hast dir angesehen, was allein die External Connector License kostet?

Ansonsten das, was Norbert sagt.

Gruß, Nils

Moin, 

Der zu lizenzierende Dienst läuft ja auf dem Windows Server, also bräuchtest du einen Connector. 

Wäre es nicht evtl. schlauer und effizienter, die User in einem Verzeichnis zu verwalten, das auch unter Linux läuft? 

Gruß, Nils

Moin, 

Prima, danke für die Rückmeldung. Dann viel Erfolg. 

Gruß, Nils

Moin,

Ein DC ist ein DC und kein Witness. Er hält also auch kein Share. Punkt. Die Abhängigkeit mag gering und leicht aufzulösen sein, aber sie ist ja vorhanden. Schöne Grüße an den Dienstleister, aber auch so ein Share läuft auf einem DC nicht mal eben mit.

Welcher eurer DCs jetzt wie lange aus ist, ist der Teil, den ich hier eben nicht einschätzen oder prüfen kann. Vielleicht muss man die Maschinen auch nicht neu machen, wenn weniger Zeit verstrichen ist. Das musst ihr dann selbst prüfen und entscheiden. 

Ist von der prinzipiellen Seite noch was unklar? 

Gruß, Nils

Moin, 

Einen DC zum Witness zu machen, ist ein schwerwiegender Designfehler. Das führt, ohne es weiter analysiert zu haben, dazu, dass du den Cluster so, wie er eingerichtet ist, nicht mehr in Betrieb nehmen kannst.

Ohne nähere Analyse müssen wir davon ausgehen, dass alle DCs an den entfernten Standort veraltet sind und nicht mehr online gehen dürfen. Das gilt dann auch für den Witness. Für den Cluster musst du also wenigstens den Witness neu einrichten, dann nicht auf einem DC.

Die Tombstone Lifetime betrifft nur DCs, keine anderen Mitglieder der Domäne. 

Gruß, Nils

Moin, 

Der geschieht zu großen Teilen automatisch. Aber ja, die Reste muss man noch selbst entsorgen. Also +1.

Gruß, Nils

Moin,

gut, dass du fragst.

Den DC auf dem "entfernten" Cluster erst mal nicht in Betrieb nehmen. Den Cluster selbst würde ich erst dann einschalten, wenn am 2. Standort Netzwerkkontakt zum Zentralstandort besteht und das Routing auch funktioniert. Dann sollten die Anmeldevorgänge funktionieren.

Wie lang die Tombstone Lifetime in eurer Domäne ist, musst du nachsehen, das können 60 oder 180 Tage sein (oder ein ganz anderer Wert, aber das wäre unwahrscheinlich). Nachsehen kannst du mit diesem PS-Kommando:

(get-adobject "cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=<domain>,DC=<tld>" -properties "tombstonelifetime").tombstonelifetime

Den Domänennamen musst du natürlich anpassen.

Falls der betreffende DC schon länger aus ist als die Tombstone Lifetime in Tagen, schaltest du ihn nicht an, sondern löschst die VM sowie das Computerobjekt in Active Directory. Dann richtest du einen neuen DC ein. Das ist in dem Fall am einfachsten.

Gruß, Nils

Moin,

vielen Dank für die Rückmeldung.

Gruß, Nils

Moin,

der springende Punkt ist, dass "VPN" häufig mit "sicher" gleichgesetzt wird, diese Gleichsetzung aber falsch ist. "Sicher" ist nur der Kommunikationskanal selbst, denn der ist verschlüsselt. Das ist aber heutzutage schon eher uninteressant, weil verschlüsselte Verbindungen (anders als vor 25 Jahren, als es mit dem Thema VPN losging) heute üblich sind. Relevant ist aber ein anderer Aspekt, und der führt dazu, dass viele VPN-Nutzungen eher das Gegenteil von "sicher" sind.

VPN legt einen Zugang in das Netzwerk, logisch betrachtet identisch mit einem Netzwerkkabel. Gewähre ich beliebigen Geräten Zugang zum Netzwerk, dann ist zwar vielleicht der Zugang "privat", aber das Netz selbst nicht mehr. Ich erzeuge damit also ein hohes Risiko, denn ich lasse Geräte zu, über die ich nichts weiß und über die ich weder technisch noch rechtlich Kontrolle und Hoheit habe. Daher ist es ein No-Go, per VPN beliebige Geräte einzulassen. Schon deshalb, weil man damit den Schlüssel für den Zugang an ein nicht kontrollierbares Gerät abgibt, von wo aus er dann ebenso beliebig weitergegeben werden kann.

Es gibt Sicherheitsberater, die die Existenz von VPN-Zugängen per se als hohes Sicherheitsrisiko einstufen.

Gruß, Nils