NilsK

Moin, *lol* ... wobei das leider nicht abwegig ist. Windows ist in manchen Fällen erfinderisch, wenn es im Code nur genügend Rückfallmechanismen gibt.* Bekannt sind in diesem Fall keine solchen Dinge, aber in deiner Situation wäre es vermutlich schlau, alle Sperren einzubauen, derer du habhaft wirst. Drei sind dir hier ja genannt worden. Gruß, Nils * ein Netzwerkspezialist erzählte mal glaubhaft, dass irgendeine Windows-Version mal versucht hat, verschobene Dateien im Netzwerk wiederzufinden und dazu dann irgendwann auch die DNS-Namensauflösung beauftragt hat, die dann z.B. nach "budget.xls" bei den Rootservern fragte.

Moin, wenn die Berechtigungen richtig gesetzt sind, können die Kolleginnen nur Gruppen anlegen und diese dann verwalten. Andere Objekte können sie nicht anlegen. Was die Konsole daraus macht, kann man nicht beeinflussen. Möglicherweise zeigt sie die Buttons an, meldet dann aber einen Fehler. Das müsste der Entwickler der Konsole steuern. An den Berechtigungen kommt man damit aber nicht vorbei. Ach, und wenn wir dabei sind: Sowas richtet man per Skript ein, z.B. mit dsacls. Dann bildet das Skript auch gleich die Dokumentation. Und man braucht eine gute Testumgebung. Erst wenn es da fertig ist, wendet man das Skript auf die Produktion an. Gruß, Nils

Moin, lol, sowas hab ich noch nicht gesehen. Das ist auch mal eine originelle Lösung. Ich verstehe es richtig, dass Horst Müller eine Termineinladung an alle schickt, in der drin steht, dass er nicht da ist? Das ist natürlich Unsinn. Sowas ist aber kein IT-Thema, sondern ein Organisationsthema. Und was die generelle Frage betrifft: Abwesenheitsübersichten sind sowohl in technischer als auch in juristischer Hinsicht immer ein schwieriges Thema. Richtig gute Lösungen gibt es dafür nicht, jedenfalls keine universellen. Aber wenn überhaupt, dann muss das von der organisatorischen Seite ausgehen. Gruß, Nils

Moin, hm ... das klingt so, als hättest du die Netzwerkfunktionen in Hyper-V grundsätzlich missverstanden. Es braucht natürlich nicht eine Netzwerkkarte pro VM. Alt, aber in den meisten Belangen noch zutreffend: [Hyper-V und Netzwerke | faq-o-matic.net] https://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Gruß, Nils

Moin, ah, OK, das hatte ich übersehen. Danke für die Rückmeldung und schön, dass es jetzt klappt. Gruß, Nils

Moin, Es muss gar nicht an deiner Datei liegen. Es kann auch sein, dass konkrete Funktionen mehr tun als die Registry zu ändern. Das ist immer ein wenig Glückssache. Gruß, Nils

Moin, was verursacht dir denn Magenschmerzen? Was spricht dagegen, die bereits bezahlte Funktion einfach zu verwenden? Gruß, Nils

Moin, tjaha, hättste mal den guten Spekulatiuskaffee genommen. Gruß, Nils

Moin, ja, so, wie es klingt, sind die Datenbanken dann in jeder Instanz separat eingebunden. Es sind also separate Datenbanken. Das mit dem Entfernen ist da die beste Idee, denke ich. Gruß, Nils

Moin, das habe ich nicht verstanden. Aber trotzdem generell gefragt: Sind die getrennten Instanzen denn nötig? Meistens sind sie es nämlich nicht. Gruß, Nils

Moin, du solltest dir angewöhnen, deine Situation und die Probleme so zu beschreiben, dass andere eine Chance haben, das zu verstehen. Leider ist das alles ziemlich atemlos heruntergerattert. Ich vermute mal, dass in den Eigenschaften deiner VM eine "Ältere Netzwerkkarte" eingerichtet ist. Diese wird in der VM als DEC/Intel 21140 erkannt. Dabei handelt es sich um eine emulierte Netzwerkkarte, deren Performance, kurz gesagt, schlecht ist. Wesentlich besser ist die "Netzwerkkarte", denn das ist eine Hyper-V-Systemkomponente. Die muss aber in der VM-Konfig enthalten sein, innerhalb der VM kann man sie nicht installieren. Gruß, Nils

Moin, Als Dienstleister bleibe ich dabei, dass das die beste kurze Antwort ist. Für Spezialfälle gibt es längere Antworten, die aber viel mehr Sorgfalt erfordern. Und mit der habe ich nach 25 Jahren als Dienstleister eben so meine Erfahrung. Gruß, Nils

Moin, bleiben die M365-Lizenzen denn? Dann käme ich nicht auf die Idee, was anderes einzusetzen als Exchange Online. Gruß, Nils

Moin, ich stimme Dukel zu. "Cloud" ist nicht gleichbedeutend mit "meine VMs nach Azure umziehen". Wenn man das tut, kostet es einfach nur unnötig viel mehr und man hat nahezu nichts gewonnen. Allgemein sind "VMs in der Cloud" eher eine Übergangs- oder Notlösung. Der Witz bei der Cloud fängt da an, wo man Dienste, also Applikationen und Funktionen, durch eine Cloud-Variante ersetzt. Erst dann ergeben sich Skaleneffekte, die der Provider kostenmäßig an dich weitergibt. Deine plakative Aussage geht da durchaus in die richtige Richtung. Wer Cloud nutzt, will das ganze Zeug ja gar nicht mehr selbst betreiben. Gruß, Nils

Moin, nein, es gibt keine Umgebungsvariable, die dir diese Daten liefert. Norbert meinte, dass die einzige Variable, die du in dem Szenario einsetzen könntest, eben die ist, die den Windows-Anmeldenamen zurückgibt. Wenn die Anforderungen so sind, wie du sie schilderst, wirst du das manuell machen oder dir selbst irgendwas bauen müssen. An manchen Stellen ist es einfacher, das zu nehmen, was da ist. Gruß, Nils

Moin, ich hab hier noch eine kleine Packung "Spekulatius-Kaffee" stehen. Da hab ich mich noch nicht rangetraut. Ich stell den mal ins Regal für die nächste Kanne. Ihr könnt dann ja berichten. Gruß, Nils PS. dass ich mal sowas schreiben würde ...

Moin, und um die nebenbei gestellte Frage zu beantworten: nein, "wir" haben keine zusätzlichen Kanäle für derartige Informationen. Die Frage, ob etwas supported ist oder nicht, ist auch keine Geheiminformation. Es kann allerdings durchaus mal sein, dass diese Info bei Microsoft nicht leicht zu finden ist. Da hätten "wir" dann aber auch keine anderen Möglichkeiten als alle anderen auch. Gerade solche Informationen bekommt man manchmal vom Support, weil man z.B. selbst oder für einen Kunden einen Call abgewickelt hat und dabei lernen musste, dass irgendwas leider nicht supported wird. In aller Regel darf man über diesen Umstand dann informieren. Es kommt durchaus vor, dass MVPs Informationen erhalten, die anderen nicht zugänglich sind. Das sind dann aber NDA-Infos (Non-Disclosure Agreement), die müssen wir dann geheimhalten. Sowas dürften wir dann also auch nicht in Videos ansprechen oder so. Typischerweise sind das allerdings auch "nur" Vorab-Informationen, die wir etwas früher bekommen als der Rest der Welt. "Früher" kann sich dabei im Bereich von Monaten (selten) oder wenigen Tagen oder Stunden (der Regelfall) bewegen. Gruß, Nils

Das ist so nicht korrekt. Das hängt vom Typ der Replikation ab. Und ob Log Shipping passt, hängt doch sehr von den Anforderungen ab. Nach dem, was bislang dazu bekannt ist, passt es ziemlich sicher nicht. Gruß, Nils

Moin, das mag alles sein, aber ich bitte den Zusammenhang zu berücksichtigen. Anscheinend ist der TO nicht mehr Herr der Konfiguration. Da macht man so einen Umbau nicht im Alleingang, sondern allerhöchstens gemeinsam mit den zuständigen Admins. Gruß, Nils

Moin, die kurze Antwort: Vergiss es. AD-Clients funktionieren genau dann gut, wenn sie den DC als primären DNS ansprechen. Die weitere Namensauflösung geht dann vom DC aus. Wenn du künftig nicht mehr Admin bist, ist ja jemand anderes für das AD zuständig. Der würde es auch kaum gut finden, wenn du einfach mal die Namensauflösung manipulierst. Also löse das mit der neuen Administration gemeinsam. Gruß, Nils PS. abgesehen davon, würde ich eine Heimlösung wie PiHole auch niemals für ein Unternehmen einsetzen, das auf das Funktionieren der Rechner angewiesen ist.

Moin, das ist aber die Perspektive von uns, die wir das seit fast 25 Jahren kennen. Wenn man sich neu damit befasst, dann ist "aktiviert/deaktiviert/nicht konfiguriert" nicht direkt eingängig. Das muss man schon erklärt bekommen. "Nicht konfiguriert" könnte man rein sprachlich auch so verstehen, dass die betreffende Einstellung abgeschaltet wird (dann wäre sie ja "nicht konfiguriert"). Dem ist ja aber nicht so. Gruß, Nils

Moin, ich hab das Problem nicht verstanden. Was spricht in den genannten Situationen gegen Visio oder draw.io? Gruß, Nils

Moin, vor dem Aufbrechen nehme ich einen halben Kaffeedrücker (French Press). In der Firma dann über den Vormittag verteilt noch einen halben. Ab spätestens 16 Uhr keinen Kaffee mehr, sonst wird mir schlecht. Nur falls es jemand wissen wollte. Gruß, Nils

Moin, du bist so gut zu mir. Gruß, Nils PS. nach all den Jahren war ich mir heute morgen nicht sicher, ob ich dazu was auf dem Blog habe ... ich meinte schon, aber ich konnte grad nicht nachgucken.

Moin, Du liegst falsch. Alles, was du zur Vererbung wissen musst, findest du bei Gruppenrichtlinien.de. Gruß, Nils