Gulp

Also, ich habe durchaus noch einen erlauchten Kreis, denen ich helfe, das beruht allerdings auch auf Gegenseitigkeit ...... und die wissen es mir jeweils angenehm zu machen, sei es mit Kaffee, alkfreiem Weizen, gutem Essen etc. Es gibt keine Diskussionen über zu ersetzende Teile oder ähnliches, es gibt keinen Zeitdruck oder so. Umgekehrt kann ich auf Motorsägen, PKW Anhänger, helfende Hände, usw zurückgreifen, damit kann ich gut leben. Merke ich, dass sich jemand aus dem Raster ausklinkt, klinke ich mich ebenfalls aus, bisher hat das so ganz gut geklappt. Stress mache ich mir deswegen aber absolut keinen, ich mache auch nur das was mir noch Spass macht, für andere Dinge habe ich dann eben keine Zeit. Grüsse Gulp

Wieso so kompliziert? Neue VM erstellen, diese zum DC machen, den alten DC depromoten, fertig. Grüsse Gulp

Für solche Szenarien gibt es doch beispielsweise die Dr Kaiser PC Wächter Software und Hardware, die setzt alle Änderungen auf den Stand, den der Admin festlegt zurück. Wird gerne in Schulen und Schulungszentren eingesetzt. Da kann der User ganz normal Sachen auf dem Desktop speichern für seine Session, sobald neu gestartet wird, wird der PC in den Sollzustand zurückgesetzt. Ich sehe gerade der Hersteller Dr.Kaiser Systemhaus wurde zur IST Berlin und das Produkt heisst nun wohl AdminDidakt ...... Grüsse Gulp

Da schliesse ich mich Nail voll und ganz an .... herzlichen Glückwunsch! Grüsse Gulp

Ich hätte da eher den 1511 Build an sich in Verdacht, wenn solltest Du einen aktuellen Builf nehmen da sind auch die entsprechenden Updates und Microcode Fixes mit drin ......... Grüsse Gulp

Ich habs gleich direkt auf ein Blech gezogen, sogar Domainmember (nein keine produktive ) mit Pro .... lief ganz geschmeidig und sogar recht fix für meinen Geschmack (gut, die Kiste hat nen Ryzen 5 3600, 16gb RAM, NVMe usw) ..... der erste Eindruck ist schonmal nicht schlecht, gefühlt findet sich alles recht schnell ..... mal abwarten. Grüsse Gulp

Das ist natürlich möglich, aber der Bluetooth Standard wird ja nicht exklusiv wie Unify für oder von Logitech entwickelt. Nachgewiesen ist derzeit nur, dass zB die Tastatureingaben per Unify eben trivial einfach ausgelesen oder welche gesendet werden können und per Bluetooth (noch) nicht, vor allem nicht "einfach so" ...... Grüsse Gulp

Ist immer noch so, da 2 der kritischen Lücken wegen Abwärtskompabilität auch erst gar nicht gefixt werden, wir verwenden daher nur Logitech Produkte die auch Bluetooth können, das ist nicht betroffen. Grüsse Gulp

Welcome back! Schön, dass Du wieder da bist! Viele Grüsse Gulp

Moin, ich habe mir in meinen HomeOffice Keller eine intravenöse Leitung für Kaffee verlegen lassen ...... Wochentag-Bezeichnungen versuche ich zu vermeiden, ich brauche jetzt auch schon abends eine Sonnenbrille wenn ich aus dem Keller nach oben gezerrt werde ...... Grüsse Gulp

Im Saarland sind die schon viel weiter mit dem Gendern, da wäre man: Es Herrmännsche .... Grüsse Gulp

Auch von mir einen herzlichen Glückwunsch und alles Gute zum Geburtstag! Grüsse Gulp

Happy Birthday nachträglich! Grüsse Gulp

Nein, Du darfst auf einem Server Standard 2 VM mit Server Standard betreiben, wenn der Hyper-V Host nichts anderes macht als die 2 VM hosten, bei Datacenter gibt es keine Limitierung. Die 2 VM's kannst Du mit dem gleichen Schlüssel wie den Host aktivieren, zur Not per Telefon, bei Datacenter geht auch die automatische Aktvierung mit den AVMA Schlüsseln. Linux VM's kannst Du so viele wie Du willst auf dem Server nutzen. Grüsse Gulp

Wir vergeben in solchen Fällen dem AD User ein temporäres Passwort, melden den User im Office am Laptop mit LAN an. konfigurieren alles Notwendige und versenden das Laptop dann wieder und vergeben dem User ein neues Einmal-Passwort. Ist der User damit nicht einverstanden, dann muss er das Laptop eben persönlich im Office abholen und dort die Schritte selbst ausführen. Grüsse Gulp

Ich sehe ehrlich gesagt nicht wo Ihr die Insider Zuordnung hernehmt. Im Screenshot jedenfalls ist das lediglich als ein Beispiel für eine Konfiguration aufgeführt (steht da auch schön in der Überschrift - da sieht man aber deutlich den Nachteil des neuen Designs aus meiner Sicht), ich habs mal auf die Schnelle markiert ....... Wie man herausfindet wo die Richtlinie herkommt wurde ja schon erschöpfend dargelegt ...... Grüsse Gulp

Die Trennung von "normalem" und "Admin" Benutzer ist doch schon ein nicht unerheblicher Sicherheitsgewinn (jedenfalls solange der normale User kein lokaler Admin ist). Man kann durchaus eine VM oder Jumpstation her nehmen, verlagert aber doch die Rechte nur woanders hin, letztlich sicherer muss das dann noch lange nicht sein. Es kommt wie Nils immer so schön sagt auf die Anforderungen an, die man an ein solches Sicherheitsmodell hat, auch an die Gegebenheiten, Personal und das Budget des Unternehmens. Das fasst man in ein schönes Konzept, testet das mal aus, verbessert hier und da und setzt es dann um. Da ist dann noch der Geltungsbereich ganz interressant, soll es für alle User oder nur einen Teil geben, welche anderen Sicherheitsmaßnahmen gibt es (getrennte Netzperimeter, Firewalls, Zugriffskonzepte etc) us usw usw, Kann schnell ein richtig großes Projekt werden ..... Grüsse Gulp

Wenn man an der Stelle zB viele Reservierungen hat, die man dann nicht neu machen will und es schnell gehen muss: Backup vom alten DHCP über die DHCP MMC in den Default Backup Ordner machen. Backup in den gleichen Ordner auf dem neuen DHCP Server kopieren Backup auf dem neuen DHCP wiederherstellen. DHCP auf altem DHCP Server deinstallieren ggfs DHCP auf dem neuen DHCP Server authorisieren. Grüsse Gulp

Hallo Franz, das Problem bei der Nummer ist aber, dass es seitens Microsoft keinen Mechanismus gibt, der eben bei installiertem Office auf einem TS solche Nutzer abweist, die kein lizenziertes Gerät haben. Hat man nun selbst keine Vorkehrung getroffen den Zugriff per Device zu regeln, gehen einem als Kunde aber die Argumente in der Diskusison aus, jedenfalls, dann wenn sich User auf mehr als einem Gerät anmelden dürfen. Da man da als Kunde eben nicht oder nur sehr schwer nachweisen kann, dass ein TS berechtigter User auch nur mit einem lizenzierten Gerät zugegriffen hat, hat man dem könnte von Microsoft ja wenig entgegenzusetzen. Zumal es die Pflicht des Kunden ist die Nutzung der Lizenz zu dokumentieren. ........ gut möglich, dass ich was diesen Punkt angeht durchaus auch extrem übervorsichtig bin, aber wie gesagt ich habe diese Diskussion im Audit führen dürfen und hier hat sich Microsoft und seine "3 Weisen" (schön gesagt ) erst besänftigen lassen und von einer empfindlichen Nachlizenzierung abgesehen, als wir die technische Zugriffslösung per Device präsentiert haben. Grüsse Gulp

Hallo Franz, das sehe ich etwas anders und kenne es aus Audits auch anders: aus den Use Rights (gibt es die PUR eigentlich noch zum Download?): https://www.microsoft.com/licensing/terms/productoffering/OfficeDesktopApplicationsWindows/EAEAS#UseRights Office (bis auf 365) wird, wie oben ersichtlich per Device lizenziert, es werden für die Remote Nutzung auf einem Server auch verpflichtend lizenzierte Geräte benötigt. Also jedes auf den Terminal Server zugreifende Gerät, muss auch ein lizenziertes Gerät sein, nach Punkt 5. User die sich ohne ein lizenziertes Gerät auf den Terminal Server verbinden, können aber auch Office verwenden und das wäre ja nach Punkt 5 nun nicht erlaubt. Ich kann auf dem Terminal Server nicht prüfen oder ermitteln , dass ein zum Zugriff berechtigter RDP User ein lizenziertes Gerät hat bzw verwendet. Ich kann also schlicht erstmal gar nicht erst nachweisen, dass ein User nur mit einem lizenzierten Gerät auf den Terminal Server zugreift, er kann das mit seinen Userdaten nämlich durchaus auch von einem nicht lizenzierten Gerät, quasi von jedem Gerät, dass im Netzwerk ist und RDP unterstützt. Das bedeutet aber aus meiner Sicht: Entweder haben alle User die auf den Terminal Server zugreifen ein lizenziertes Device (das kann durchaus bei den meisten Konstrukten der Fall sein und den Standard darstellen) oder ich muss sicherstellen, dass sich eben kein anderes Gerät auf den Terminalserver verbinden kann, als diese lizenzierten Geräte. Dies kann ich aber letztlich nur, wenn ich den Zugriff auf den Terminal Server explizit nur für bestimmte Geräte erlaube, also bespielsweise per Hardware basierter Erkennung auf Netzwerkebene. Erst als wir bei einem Lizenz Audit nachweisen konnten, dass wir technisch einen physikalischen Zugriff auf den Terminal Server für nicht lizenzierte Geräte verhindern, hat Microsoft von einer nicht unerheblichen Anzahl von Nachlizenzierungen von Office abgesehen. Die oben genannten Punkte sind so auch in älteren PUR's, die jetzt keine Gültigkeit mehr haben, enthalten und wenn diese immer noch unverändert Bestand haben (was ja offensichtlich der Fall ist), so würde ich bei einem Audit durchaus weiter meiner Ansicht sein. Wenn es mittlerweile anders gehandhabt wird, schön, ich für meinen Teil habe bei uns durchsetzen können, dass keine Office Desktop Applikationen mehr auf Terminal Servern bereit gestellt werden. Grüsse Gulp

Hmm ohne die tatsächlichen Gegebenheiten bei Hetzner zu kennen wird das auch schwer. Üblicherweise nimmt man beim Hyper-V Host mehr als eine NIC, alleine damit man sich nicht mal so eben aussperren kann. Da stellt sich halt die Frage wie die Netzkonfig insgesamt so aussieht, hast Du in dem Netz in dem die Hyper-V NIC hängt nur die eine IP, wird es ohne NAT schwer ...... Hyper-V kennt allerdings auch einen NAT Switch, das muss man aber über die PowerShell einrichten, ich hab damit mein Testlab vom "normalen" IP Bereich abgetrennt. Im nachfolgenden Link wirds erklärt: (oder Google mal nach Hyper-V NAT Switch) https://www.windowspro.de/wolfgang-sommergut/nat-switch-hyper-v-einrichten-windows-10-server-2016 Ich habe im normalen Produktivnetz 192.168.0.0/24 ...... da läuft DHCP, mein NAT IP Bereich ist 192.168.222.0/24, da muss ich die IP's aber händisch vergeben (will ich so ) ..... der Hyper-V NAT Switch bekommt die 192.168.222.1, das nimmst Du bei den Clients die NAT nutzen dann als Gateway. Grüsse Gulp

AppData umzuleiten ist keine gute Idee und funktioniert auch meist nicht, siehe Seite 1, Beitrag 10 in diesem Thread. Was erhoffst Du Dir von sowas eigentlich, bei Roaming Profiles wird zumindest AppData\local per Default auch ausgelassen (wie noch ein paar Folder aus dem eigentlichen Profil), das Argument für Roaming Profiles kann es ja dann nicht sein oder? Hier noch ein bisschen Lesestoff .... https://www.gruppenrichtlinien.de/artikel/unbrauchbar-und-kaputt-roaming-user-profiles-serverbasierte-profile Grüsse Gulp

Man kanns halt nicht oft genug sagen ....... Grüsse Gulp

Office Anwendungen werden immer per Device lizenziert (ausser 365), will heissen jedes Gerät, dass sich per RDP auf den TS verbinden kann, muss auch eine entsprechende Lizenz haben .... hast Du nur die 5 Lizenzen, musst Du technisch sicherstellen, dass kein anderes Gerät, bzw nur die 5 Geräte mit der Lizenz sich per RDP auf den TS verbinden können. Da brauchst Du schon jetzt mindestens 2 TS, einen für Project 2013 und einen für Project 2016 ....... Da sind schon ein Haufen Leute beim Audit mit großen Augen aus der ersten Sitzung herausgegangen und durften eine Menge Office Lizenzen nachkaufen ...... Grüsse Gulp

Wenn alle betroffenen User das gleiche Logonscript verwenden solle, dann würde ich, wenn es schnell gehen muss, einfach das Script selber wegsichern und das neue unter dem vorigen Namen speichern, eine Kommentarzeile rein und allen wäre erstmal geholfen ........ Im Nachgang kann man dann ja dann in aller Ruhe die Scripte konsolidieren. Grüsse Gulp