NilsK

Moin, ähm ... für drei Mitarbeiter? Ich glaube nicht, dass das so sinnvoll ist. Kosten und Nutzen scheinen mir da in ungünstigem Verhältnis zu stehen. Gruß, Nils

Moin, wie hast du es denn in VBA gelöst? So unterschiedlich sind die Dialekte ja nicht. Und was hast du mit welchem Ergebnis in VBS versucht? Die Methode "FolderExists" und die Collection "Folders" sind dir bekannt? Gruß, Nils

Moin, ja, nervig sowas. Leider habe ich (auch) keine Lösung dafür. Gruß, Nils

Moin, ich brauche überhaupt keine. Du brauchst sie. Ohne weitere Angaben ist "nimm einen NAS oder einen Dateiserver pro Seite" eine ausreichende Lösung. Was du da hin- oder herkopieren willst, habe ich nicht verstanden, aber das ist dann eben das, wo die einfache Lösung vielleicht nicht ausreicht. Gruß, Nils

Moin, ich nehme an, dass das eher ein lokales Problem ist als irgendwas, was "aktuell" von Teams kommen würde. Leider ist Teams manchmal tatsächlich etwas hakelig, wenn es um das Ansprechen von Geräten geht. Das hängt nach meiner Einschätzung/Erfahrung aber eher mit dem konkreten Gerät bzw. Treiber zusammen. Gruß, Nils

Moin, mpf. Nee. ESAE ist so dermaßen viel mehr als "eine weitere Domäne mit Trusts", dass ich es in diesem Kontext fast abwegig finde. Der TO ist noch viel weiter "vorne" und möchte erst mal Basics bereitstellen. Da sollten wir ihm nicht als erstes mit einem der komplexesten Entwürfe kommen, die es gibt. Gruß, Nils PS. Die beste Security ist die, die man auch umsetzt. ESAE-Konzepte tendieren leider dazu, in der Schublade zu bleiben.

Moin, @djmaker und @Nobbyaushb, ihr seid auf dem falschen Dampfer. @SaschaVolk man kann das sicher alles machen, aber dazu können wir gar nichts sagen, ohne die Anforderungen zu kennen. Ob man nun einen Windows Server oder ein Appliance-NAS nimmt, hat für die Sicherheit nur sehr indirekt eine Auswirkung. Und wie du den Dateiaustausch organisierst, ist eben eine Frage der Anforderungen. Gruß, Nils

Moin, Okay, dann hatte ich das missverstanden. Es geht also darum, eine komplett neue Domäne in einem neuen Forest einzurichten. Das könnte man tun, aber ... ... es würde ja keins der Ziele des TO erreichen. Es geht ihm nicht um eine Admin-Domäne, sondern er will, dass die User sich überall anmelden können. Dafür braucht man Vertrauensstellungen zwischen allen Domänen, und dafür wiederum wäre eine zusätzliche Domäne keine Hilfe, sondern würde die Sache nur noch komplexer machen. Statt vier einzelner Domänen gäbe es dann fünf. Gruß, Nils

Moin, Nö, genau das geht ja nicht. Wenn man möglichst wenig Arbeit will, richtet man erst mal Vertrauensstellungen zwischen allen Domänen ein. Und wenn man es dann später richtig machen will, macht man genau eine Domäne für alles und migriert alles da rein. Gruß Nils

Moin, Naja ... Es ordentlich zu machen, hätte vielleicht 30 Minuten länger gedauert. Dafür würde ich nicht mag drüber nachdenken, etwas möglicherweise nicht Supportetes zu machen. Gruß, Nils

Moin, Aber warum überhaupt? Warum es nicht richtig machen und einen zweiten DC dazu installieren? Dann den Eval runterstufen und weg damit. Und überhaupt: eine Eval ist nicht für Produktion zugelassen. Also kann es ja kaum sein, das da eine produktive Installation drauf ist. Oder wie siehst du das? Gruß, Nils

Moin, nehmen wir den, da ist kein Disclaimer dabei: https://docs.microsoft.com/en-us/windows/win32/adschema/a-telephonenumber Es lebe die redundante Inhaltsablage. Gruß, Nils

Moin, kurz: nein. Es kann aber sein, dass künftig Anwendungen mit dem alten Modus nicht klarkommen. Neben Exchange gibt es da aber nur wenige. Allerdings: Wenn ihr keine alten DCs mehr habt, dann spricht auch nichts (= null) dagegen, den Modus hochzustellen. Dauert in den meisten Umgebungen fünf Minuten und hat, kurz gesagt, keine Risiken. Gruß, Nils

Moin, wenn ihr Exchange habt, bieten sich immer dessen Extended Attributes an. Es gibt auch ein Pendant dazu, das sind die Cloud Extension Attributes. Sonst gib es noch hunderte weitere - ob die geeignet sind, legt man am ehesten selbst organisatorisch fest. Dass nach über 20 Jahren noch kommerzielle Produkte ankommen, die so ein Attribut ihrerseits verwenden und davon abhängig sind, ist doch eher unwahrscheinlich. Gruß, Nils

Moin, das, was Martin sagt. Plus den Hinweis: Eine technische Absenderangabe dient zur Identifikation. Titel und sonstiges (Selbst-) Marketing sind in einer Signatur richtig aufgehoben. Da darf man auch mal eine politische Entscheidung treffen. Gruß, Nils ... der diese Sorte Diskussion zuletzt in mit einem Kirchenkunden führte ... beeindruckend, welche Vielfalt an Titeln es da gibt.

Moin, möglich ist vieles. Für mich lag der Gednke jetzt nahe, weil es mit PDF ja anscheinend die Verzögerungen nicht gab. In Zips und Office-Dokumente gucken viele Scanner halt genauer rein. Gruß, Nils

Moin, ich tippe mal: Da ist ein Virenscanner im Spiel. Gruß, Nils

Moin, "gehen" müsste es ja von allen Seiten. Der Server müsste damit umgehen können und der Client. Da sowohl Server als auch Client in diesem Szenario sehr unterschiedlich sein können, würde ich den Abbruch des Exchange-Assistenten schon als sehr starkes Indiz werten, dass das aussichtslos ist. Abgesehen davon, sind Wildcard-Zertifikate Murks in Bezug auf Sicherheit. Und das widerspricht dann irgendwie dem Sinn des Ganzen. Gruß, Nils

Moin, Text in Anführungszeichen? Manche Parser akzeptieren dann auch Zeilenumbrüche. Gruß, Nils

Moin, DHCP nicht auf einem DC. Das macht man nur noch in Kleinstumgebungen. Sonst ist sowohl Security als auch Continuity ein Problem. Gruß, Nils

Moin, löst das organisatorisch. Werft nicht mit Technik drauf. Mein Ausgangspunkt wäre: Eine Person hat genau eine Mailbox, mit der sie arbeitet. Und das, was dranhängt. Gruß, Nils

Moin, kurze Anmerkung dazu: Ich beobachte es auch immer mal wieder, dass Exchange den Terminstatus im Kalender nicht richtig setzt. So habe ich mehrere Termine in meinem Kalender, die als "noch nicht zugesagt" bzw. "unter Vorbehalt" kategorisiert sind, obwohl ich zugesagt habe. Andersrum bekomme ich manchmal von Kollegen mehrere Zusagen auf denselben Termin, weil sie offenbar dasselbe Problem haben. Nur sporadisch, nicht immer. Scheint mir eine Fehlfunktion zu sein, keine Frage der Konfig. Gruß, Nils

Moin, eben, es sind ja keine neuen Sachen. Das geht seit 20 Jahren. Wenn es da ein Problem bei euch gibt, solltet ihr halt miteinander reden. Dann wird das Problem eher sein, dass deine Kollegen nicht verstehen, was das soll. (Ich verweise auf meine erste Frage in diesem Thread.) Gruß, Nils

Moin, ehrlich gesagt nicht. Das ist Exchange-Grundfunktion, da gibt es nichts nicht zu gehen und keine magischen KB-Artikel. Am Ende ist es eher eine Frage von: Anforderungen definieren und miteinander reden. Gruß, Nils

Moin, das Recovery führt der SQL Server immer beim Neustart aus, egal wie die DB konfiguriert ist. Es geht ja gerade um den aktiven Teil des Transaktionsprotokolls, der ist immer vorhanden (und genau dafür gedacht). Der Startmodus des Dienstes hat damit nur sekundär zu tun. Wenn der SQL Server später startet, dann fängt er halt auch erst später mit dem Recovery an. Gruß, Nils