NilsK

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

Moin, Mal andersrum gefragt: was ist denn das Ziel der Aktion? Gruß, Nils

Moin, und daher stellte ich die Frage, was denn nun eigentlich das Ziel ist. Wir können jetzt lange philosophieren, was man so alles machen könnte, aber wenn der TO nicht sagt, was denn eigentlich erreicht werden soll, nützt das nix. Irgendwie immer dasselbe ... Gruß, Nils

Mopin, was richtest du denn da genau ein? Und was ist das Ziel bzw. die Anforderung dahinter? Gruß, Nils

Moin, ein Server kommuniziert immer über die IP-Adresse. Die Frage ist, wo er die herbekommt, und das weiß nur der Server selbst. Entweder ist die Adresse in der jeweiligen Konfig hinterlegt oder ein Name, den der Server dann erst auflösen muss. Da musst du also auf die jeweiligen Konfigs schauen. Gruß, Nils

Moin, wenn derjenige das nicht sagen kann, der es vermutlich draufgebracht hat, dann: mach die Kiste neu. Du hast sie ja offenkundig nicht unter Kontrolle, kannst dir also auch nicht sicher sein, dass das überhaupt Crowdstrike ist. Gruß, Nils

Moin, das klingt nicht gut. Ich würde die Rechner schnell platt machen und sauber neu einrichten. Und schauen, ob es noch anderswo im Netzwerk Probleme oder Auffälligkeiten gibt. Gruß, Nils

Moin, das ist das, was Evgenij als "halb/halb" bezeichnet. Ein Rechner in der Domäne heißt: die Domäne vertraut dem Rechner und darf das auch. Dann darf aber niemand diesen Zustand stören, also darf nicht "irgendwas" dort installiert werden. Das sind in deinem Szenario externe Geräte vom Typ "untrusted". Du brauchst dort auch keine GPOs - die würden dir sowieso nix nutzen, wenn du den Adminzugang nicht kontrollierst. Gruß, Nils

Moin, das meinte ich mit: Gruß, Nils

Moin, sowas ist schon möglich. Es ist aber technisch durchaus komplex, daher landet man schnell bei einer ausgewachsenen IdM-Lösung, die "eigentlich" für so eine organisatorisch eher kleine Sache (so jedenfalls die Einschätzung bei vielen Unternehmen) zu groß ist. Die Lösung, die du gefunden hast, geht ja in die Richtung - auch preislich. Die kann dann aber auch nur das eine und ist kein vollständiges IdM. Gruß, Nils

Moin, am Ende ist das eine von den Fragen, die man ohne konkrete Anforderungen nicht näher wird beantworten können als "kommt drauf an". Gruß, Nils

Moin, was du beschreibst, ist ein möglicher Weg. Allerdings eher ein umständlicher. In der Cloud, insbesondere der von Microsoft, gibt es eine ganze Reihe anderer Möglichkeiten. Man kann OneDrive nutzen, kann kann mit Teams arbeiten - es gibt Unternehmen, in denen ein klassischer Fileserver kaum noch eine Rolle spielt. Andere Unternehmen erweitern ihr lokales Netzwerk um VMs, die in der Cloud laufen, und binden diese per VPN an. Am Ende zählt das, was die jeweilige Anforderung am besten erfüllt. Gruß, Nils

Moin, Ja, gpmc.msc ist die Verwaltungskonsole für die Struktur. Nicht der Editor. Edit: um noch eben anzumerken, warum ich dieses Fass überhaupt aufgemacht habe: Wichtig ist vor allem die Unterscheidung von gpedit.msc einerseits und AD-Richtlinien andererseits. Das ist vielen Admins nicht klar, und ich erlebe es oft, dass Admins irgendwas in gpedit.msc einzustellen versuchen und sich dann wundern, dass das nicht geht wie gewünscht. Die Detaildiskussion, die daraus jetzt entstanden ist, ist zugegebenermaßen Off-Topic-Besserwisserei. Gruß, Nils

Moin, also ... schlagt mich, aber ich bin der Meinung, es ist gpme.msc. gpedit.msc verwaltet die lokalen Richtlinien. Starte ich den, steht in der Titelleiste "Editor für lokale Gruppenrichtlinien". Ich kann keine andere Richtlinie auswählen als die lokale. Der Editor, mit dem ich die AD-GPOs verwalte, hat in der Titelleiste "Gruppenrichtlinienverwaltungs-Editor", wie auch in den Screenshots oben in diesem Thread zu sehen ist. Den kann ich über die GPMC öffnen oder aus dem System32-Verzeichnis als "gpme.msc". Mache ich dies, dann fragt der Editor, welche AD-Richtlinie es denn sein soll (weiter komme ich hier nicht, bin nur Anwender). Das sieht man auch im Taskmanager, wenn man die Befehlszeile einblendet: Gruß, Nils

Moin, nein, das ist die Konsole, die die GPO-Links verwaltet. Ich meine den Editor, der erscheint, wenn man ein GPO zum Bearbeiten öffnet. Das ist doch gpme, oder? (Hab gerade keine VM zum Nachsehen ... neuer Job ...) Gruß, Nils

Moin, warum das fehlt, ist doch völlig egal. Ich würde das auf den DCs auch nicht troubleshooten, sondern dafür sorgen, dass ich eine vernünftig funktionierende Admin-Workstation habe. Dinge wie diese bearbeitet man niemals direkt auf einem Server, schon gar nicht auf einem DC. Es gibt so gut wie keinen Grund, sich im Tagesgeschäft lokal oder per RDP an einem DC anzumelden. Es ist übrigens nicht gpedit, damit bezeichnet man den Editor für lokale Gruppenrichtlinien. Technisch betrachtet, ist es gpme (meine ich). Gruß, Nils

Moin, Anzeigeproblem. Auf dem einen Server existiert die DLL, die das anzeigt, auf dem anderen nicht. Das ist ein Grund, warum man die Administration nicht auf Servern macht, sondern auf Adminrechnern, die eine kontrollierte und gepflegte Konfiguration haben. Zu dem Druckerthema selbst kommen bestimmt auch gleich noch Meinungen. Gruß, Nils

Moin, ich verstehe die Frage nicht ganz. Wenn die Benutzer eine Termineinladung akzeptieren, ändert sich ja der Status für die Einladung des Raumes nicht. Technisch betrachtet, ist der Raum ein separater Teilnehmer. Oder meinst du die Frage anders? Was hast du denn für den Raum konfiguriert? Gruß, Nils

Moin, ja, das ist das Problem, wenn die Leute immer nur nach genau dem Detail fragen, mit dem sie gerade beschäftigt sind, aber den Zusammenhang weglassen. Ich mutmaße mal: vielleicht gibt es pro "Produkt" etwas, z.B. eine HTML-Seite, das auf die Bilddatei verweist. Ändert man das nun bei einem Produkt und dasselbe Bild wird auch noch von anderen Produkten verwendet, dann ist bei diesen anderen Produkten der Pfad ungültig. Aber bevor wir hier weiter rumraten, sollte der TO endlich mal beschreiben, was denn nun Sache ist. Immerhin versucht er im urprünglich geposteten Code ja, dieselbe Datei mehrfach umzubenennen, was ja nicht funktionieren kann. Da wird was dahinterstecken. Gruß, Nils

Moin, das könnte der Fehler sein. Siehe: https://social.technet.microsoft.com/Forums/windowsserver/en-US/b17c798c-c4b2-4624-926c-4d2676e68279/dns-record-ownership-and-the-dnsupdateproxy-group Abgesehen davon: Bitte hänge dich nicht an andere Fragen an. Auch wenn scheinbar "exakt das gleiche" vorliegt, ist es bei näherem Hinsehen praktisch nie so. Eröffne bitte einen eigenen Thread, wenn du eine Frage stellst. Danke- Gruß, Nils

Moin, ergänzend zu Norberts Hinweis: Die Registry ist nichts Magisches, sondern nur eine Datenbank, in der Einstellungen stehen. Änderungen an der Registry verursachen von selbst erst mal nichts, sondern Programme können darauf reagieren. In den allermeisten Fällen ist es unkritisch, dort Werte zu ändern. Das ist technisch betrachtet nichts anderes, als wenn man in einem Programm z.B. ein Häkchen ein- oder ausschaltet. So ist das auch in diesem Fall - die Besonderheit ist hier, dass es für die betreffende Einstellung kein Häkchen gibt, weil der Entwickler der Software die Einstellung nicht für so bedeutend hält, dass er dafür eine Einstellungsseite mit Häkchen vorsieht. Grundsätzlich ist es schon sinnvoll, in der Registry nicht einfach drauflos zu ändern. Aber Magie ist es nicht, insbesondere, wenn es nicht um Kernkomponenten des Betriebssystems geht. Gruß, Nils