Gulp

Die bleiben ja weiter aktiv. Jetzt will er zusätzlich 2 mit Server 2016. Die 2 "kostenlosen" VM's bei Standard gibt es ja nur wenn auch der Host unter dem jeweiligen OS läuft (zuweisen reicht da nicht, es muss ausgeführt werden), das tut es ja dann nicht, denn der liefe ja weiter unter 2012R2. Da kannst Du dann nur noch die einzelnen zusätzlichen VM's lizenzieren. Grüsse Gulp

Eine 2016er Lizenz reicht da dann sicherlich nicht für 2 VM's, denn dann müsste der Host auch auf 2016 laufen. Ich wüsste jetzt aber auch nicht was gegen die Verwendung von 2 verschiedenen Lizenzen auf einem Host spricht. Ich kann doch auch 5 Lizenzen einer Hardware zuweisen, wenn ich die separat kaufe, dann kann ich zwar die "kostenlose" VM nicht nutzen und muss für jede VM eine Lizenz haben. Grüsse Gulp

Ich wette, das ist aber eher Absicht und liesse sich mit einer oder mehreren Route recht fix konfigurieren, wäre zumindest so bei uns. Im Unternehmensumfeld mit mehreren Standorten sollte es eher der Standard sein alle Netze der jeweiligen Standorte (also Sites) miteinander zu verbinden. Hat man als Firma XY einen Standort A und B verbindet man aus meinem Verständnis zunächst bei der Planung immer zunächst alle Netze der jeweiligen Standorte generell. Sicherlich ergeben sich dann je nach Unternehmensstruktur und den jeweiligen Gegebenheiten, Anforderungen und Detailplanungen auch Einschränkungen oder Notwendigkeiten bestimmte Netze nicht zu routen, aber das würde ich immer von "erlaube alle Netze" herunterbrechen und nicht erst mal nur ein Netz verbinden. Grüsse Gulp

/Offtopic: ...... aber vielleicht Voodoo? *duck-und-weg* Grüsse Gulp

Also bei uns beinhaltet Site-to-Site auch alle Netze der jeweiligen Sites, deswegen auch die Nachfrage, weil sowas eben nicht ohne Routing im VPN gehen kann und bei mehr als einem vorhandenen Netz eines davon mit einem anderen koppeln Site-to-Site nennen ist schon sportlich. Nichts für ungut, aber ich würde da jetzt nicht mehr groß rumbasteln wollen und das Netz ordentlich neu planen und aufziehen, dann klappt das zum einen mit der Replikation und erleichtert die zukünftige Fehlersuche ungemein. Grüsse Gulp

Was denn nun? Im ersten Post schreibst Du die Replikation funktioniert und jetzt tut sie es nicht oder nur manchmal? Sieht man mal wieder wie detaillierte Fehlerbeschreibungen im Endeffekt aussehen. Rein interessehalber, wie bekommt man denn so ein VPN hin? Grüsse Gulp

Nö, das Problem ist laut TO ja nur aufgefallen, weil das neue VPN nicht alle Netze vom DC routet, sondern nur eines, aber der andere DC alle kennt und es hier und da schonmal auf einem anderen Netz mit Ping nach dem Namen versucht. Grüsse Gulp

Die Domain Member sind ja dabei auch das kleinste Problem ....... ;-D Wie gesagt, quick'n'dirty einen Linux Router hinstellen der das an Stelle des DC's macht und den DC einfach DC sein lassen, dann kann man zur Not auch die verschiedenen Netze eine gewisse Zeit einfach so lassen (auch wenn ich dann wieder beim drüber nachdenken leicht mit dem Schüttelfrost anfange). Grüsse Gulp

Ich lese da was von er weiss es nicht genau ..... Nur an der Aktivierung kann man es nicht festmachen, es mag seit dem "digital entitlement" eventuell darauf hindeuten, aber als Nachweis taugt das eher kaum. Grüsse Gulp

Im Endeffekt wird man das Netz neu planen müssen und dann nachfolgend die Zugriffe über ein ebenfalls zu planendes Zugriffsmanagement regeln. Wie Nils immer zu sagen pflegt: Erst die Anforderungen möglichst genau definieren und dann schaut man weiter was man zur Umsetzung alles braucht. Das wird aber meist den Rahmen eines Forums sprengen dürfen. Grüsse Gulp

...... ich wunder mich auch gerade, dass ich das so fehlerfrei schreiben konnte, bei dem Ausdruck "Multihomed DC" kriege ich sonst immer sofort Lidflattern und ordentlich Schüttelfrost. EDIT: Zunächst sollte man wohl auch prüfen, ob man wirklich so viele verschiedene Netze braucht, zur Not kann man das mit einer kleinen Linuxkiste spontan abfangen und sich dann auf die Suche nach etwas Vernünftigen für das zur Verfügung stehende Budget machen. Hat man genügend Lizenzen kann man auch einen Windows Server dafür nehmen, nur der DC sollte es nicht sein. Grüsse Gulp

Ganz so einfach dürfte es nicht sein, aber durchaus für beide Seiten. Der kostenlose Upgrade Zeitraum ist ja schon länger vorbei, dennoch lassen sich auch jetzt noch frische Windows 10 Installationen mit Windows 7 Schlüsseln upgraden, lediglich der 7er Schlüssel muss vorher schon mit Windows 7 aktiviert worden sein. Streng genommen dürfte das nicht mehr legal sein, es dürfte aber auch schwierig sein das zweifelsfrei und vor allem wirklich belastbar nachzuweisen. Im Unternehmen wäre mir so ein Zustand doch eher zu unsicher ....... da hätte ich dann doch lieber einen ordentlichen Lizenznachweis. Grüsse Gulp

Einen Grund hast Du ja jetzt schon gefunden ....... Grüsse Gulp

Wenn es jetzt auch fast vorbei ist, da hoffe ich trotzdem ihr hattet, so wie ich, geruhsame und fröhliche Weihnachten im Kreise Eurer Lieben! Grüsse Gulp

Das Problem mit solchen 3rd Party Tools, wie auch bei O&O ShutUp ist immer das Gleiche, man weiss nie was die da tatsächlich tun. Natürlich ist auch der Client ein Baustein bei einem Datenschutzkonzept, ich vermisse bei solchen in die Runde geworfenen Datenschutz "Thesen" immer einen entsprechenden Konzeptgedanken. Da wird fröhlich dem BSI und Heise nachgeplappert, die hier, sicher nicht zu Unrecht, die Situation in Behörden beleuchtet haben. Die dort getroffenen Schlußfolgerungen sind sicherlich zulässig und nicht per se falsch, lassen sich aber nur eingeschränkt auf Firmen und noch weniger auf das private Umfeld übertragen, da dort zum Teil deutlich andere Anforderungen, Vorschriften und gesetzliche Vorgaben für den Umgang mit Daten und deren Schutz zum Tragen kommen. Der größere Teil des sogenannten "Dilemmas" geht aber auf die Lizenzkosten, der Abhängigkeit, des Kontrollverlustes des Staates über die IT und die Vergabepraxis der Aufträge ein und nicht in erster Linie mit dem Datenschutz. Eine solche Monopolstellung gibt ja nicht nur in der IT, da gibt es genügend weitere Beispiele. Grüsse Gulp

Zum einen arbeitet man bei der imagebasierten Clientverteilung mit sysprep, da passt man nur das Default Profil an und verwendet eine entsprechende XML für die restliche Konfiguration: https://msdn.microsoft.com/de-de/library/windows/hardware/dn938334(v=vs.85).aspx Zum anderen benötigt man auch eine passsende OS Lizenz, da Du nicht mit jeder Windows 10 Lizenz einfach so Clients betanken darfst, ich kann nicht genau sagen, ob heute mit Windows 10 eine einzige Vlumemlizenz für das Re-Imaging noch reicht (früher ging das noch), in den Volumenlizenzen ist jedoch zumeist das Re-Imaging Recht eingeräumt. Das kann lizenzdoc aber bestimmt besser im Detail beantworten. Grüsse Gulp

Klar, den Weihnachtsmann gibt es wirklich! Du willst mir sagen, Du überwachst alle Windows Updates und deren Auswirkungen? Träum weiter und komm das nächste Mal erstmal in meinen Aluhut-Verleih. Aber jedem wie es gefällt und wenn es Dich glücklich macht. Ich an Deiner Stelle hätte das OS gewechselt, dann bräuchtest Du den ganzen Aufwand nicht und könntest Deine Zeit sinnvoll einsetzen. Grüsse Gulp

Wer nur am Client die Telemetrie abschaltet, hat meiner Meinung nach das Thema Datenschutz auch nur eingeschränkt bis gar nicht verstanden. Das sind die Leute die zumeist in Facebook vom Essen bis Toilettengang alles öffentlich mitprotokollieren und dann nach Datenschutz schreien, wenn der Programmabsturz an den Hersteller mit zusätzlichen Debugdaten übermittelt wird. Solche Telemetriedaten insbesondere deren Zieladressen kann man in der Regel bequem per ordentlich konfigurierter Firewall Appliance samt und sonders abfangen. Es muss jedem klar sein, dass auch Microsoft immer mehr auf SaaS setzt und mittlerweile auch in Enterprise extern die Telemetriedaten fast jederzeit wieder anschalten kann, einfaches KB Update oder das vierteljährliche Funktionsupdate genügt, zumal immer mehr GPO's auch weggelassen/unwirksam werden können (derzeit nur bei Pro, aber wer sagt, dass es bei Enterprise nicht auch irgendwann kommt). Wer da nur den Client im Auge hat, denkt meiner Ansicht nach deutlich zu kurz und zu naiv, da für den ordentlichen Datenschutz deutlich mehr in Betracht gezogen werden muss. Man muss allerdings auch erwähnen, dass auch Microsoft sich an geltendes Recht halten muss und seine Telemetriedaten ohne speziellen Benutzerbezug erheben muss. Inwiefern das umgesetzt ist, kann ich zwar auch nicht vollständig sagen aber im allgemeinen haben meines Wissens nach bisherige Tests (unter anderem von heise) immer ergeben, dass die Daten die erhoben wurden, reine Fehlermeldungen mit Debuginformationen oder nicht benutzerbezogene Nutzungsdaten beinhalteten. Eine gewisse Vorsicht ist sicherlich nicht schlecht, solche aber Enterprise zuhause wegen dem Datenschutz einsetzen zu wollen, ist für mich mit Kanonen auf Spatzen geschossen. Grüsse Gulp

Wenn ich mal zwischendurch Zeit habe, gucke ich mal genauer danach. Ich meine zwar, dass ich im Laufe der Analyse auch schon mit /resetauthorization gespielt habe, aber wenn ich mich da recht entsinne klappt das dann immer nur genau ein Mal, danach kann ich /detectnow aufrufen sooft ich will und es tut sich nichts, halt im Gegensatz zum UsoClient (vielleicht bin ich auch nur zu ungeduldig, aber im Testlab will ich keine 2 Stunden warten bis er nach dem Boot Updates findet und anzeigt, das soll mehr oder weniger direkt losrennen). Mein Begehren ist ja so auch nicht unbedingt der Regelfall und im Augenblick klappt es bei mir so wie ich mir das vorstelle und wenn es bei Euch auch anders herum klappt, ist das auch schön. Ist jetzt aus meiner Sicht im Testlab auch kein großes Ding, vielleicht hilft es ja als Alternative jemandem, der ein ähnliches Problem mit /detectnow fetstellt. Grüsse Gulp

Meine Erfahrungen decken sich mit dem Blogeintrag, ich kann in einer administrativen CMD 20 Mal wuauclt /detectnow ohne Ergebnis aufrufen, mit dem UsoClient geht's halt dann (mit 2 verschiedenen Clients gestestet), der Schalter /reportnow ist gefühlt auch nicht so fix wie der UsoClient, wobei /detectnow nach Stunden noch kein Update gezogen hatte, obwohl der Report Updates ausgewiesen hatte. Ist mir auch ohne den Blogeintrag aufgefallen, den habe ich aufgrund der Beobachtung dann gefunden. Da ich bei meiner Testumgebung mit Maschinen arbeite die nur sporadisch gestartet werden und daher per Skript zum Start wuauclt /detectnow und wuauclt /reportnow ausführen sollen, um direkt neue Updates zu finden und herunter zu laden, die ich dann wenn ich die Maschine brauche vor der Benutzung direkt einspielen kann ohne lange Wartezeit. Da wunderte es mich dann irgendwann als die Maschinen keine Updates hatten, nach der Umstellung auf den UsoClient im Skript, klappt das wie vorher bei 7 und 8.1. Grüsse Gulp

Der Schalter /detectnow geht leider unter Windows 10/Server 2016 (und vermutlich bei den Nachfolgeversionen auch) nur nicht mehr, da muss es stattdessen heissen: c:\windows\system32\UsoClient.exe startscan siehe: https://blogs.technet.microsoft.com/yongrhee/2017/11/09/wuauclt-detectnow-in-windows-10-and-windows-server-2016/ Grüsse Gulp

Zumal Client OS Lizenzen lediglich Upgrade Lizenzen sind, man braucht also ohenhin vorher ein qualifiziertes OS, zB ein Windows 10 OEM/SB als Upgradebasis ....... Grüsse Gulp

Wir nutzen Matrix42 Empirum für die Softwareverteilung. Grüsse Gulp

Derzeit testen wir das Ausrollen der Funktionsupdates mit unserer Softwareverteilung, da können wir den Zeitpunkt der Installation deutlich besser steuern als über den WSUS. Bisher führen wir die Funktionsupdates manuell und nur bei Bedarf vom ISO aus. Grüsse Gulp

Och nöö wieder Doppelaccounts zum Selbstgespräche führen oder wie? Was ist an der Fehlermeldung "Fehler bei der Anmeldung. Fehler bei der Anmeldung für den Benutzer 'Administrator'." so unklar? Grüsse Gulp