Gulp

So seltsam ist das nicht: https://docs.microsoft.com/de-de/windows/deployment/vda-subscription-activation Grüsse Gulp

Jo -ipk hatte ich gemeint, sorry war ein Typo. Grüsse Gulp

Sollte in einer administrativen CMD mit slmgr.vbs -apk 12345-12345-12345-12345-12345 (Deinen Key anstatt des 12345 Geraffels eintragen) und anschliessendem slmgr.vbs -ato aktiviert werden können. Grüsse Gulp

Man lizenziert immer den physikalischen Host und nicht die VM's, also eine für den ESXi Server und seine Cores passende (mindestens aber 16 Cores) Datacenter Lizenz und die VM's sind dann damit abgedeckt, da der Datacenter beliebig viele VM's hosten darf. Grüsse Gulp

https://www.microsoft.com/en-us/licensing/product-licensing/client-access-license User CALs With the User CAL, you purchase a CAL for every user who accesses the server to use services such as file storage or printing, regardless of the number of devices they use for that access. oder https://blogs.msdn.microsoft.com/mssmallbiz/2007/11/06/licensing-basics-what-are-cals-client-access-licenses/ User CAL – A User CAL allows a single unique physical user to access Microsoft server software from many devices, such as a work computer, a home computer, a laptop, an Internet kiosk, or a personal digital assistant (PDA), without having to acquire CALs for each device. Grüsse Gulp

Es heisst ja User CAL oder Geräte CAL und nicht Postfach CAL, was lernen wir daraus: nur Geräte und Menschen brauchen CAL's, Postfächer und Accounts brauchen keine ........ Grüsse Gulp

Die Meldung kommt wohl eher deswegen, weil die Verbindung mit Windows Update Internetadressen möglich ist und daher das Feature Update auf 1809 gefunden werden kann, wir deaktivieren bei uns diese Verbindung und Clients mit älteren Builds erhalten diese Meldung daher nicht. Hier muss man sich dann nur Gedanken über das Ausrollen der Versionsupdates machen, wir werden das, so wie die Tests bisher aussehen. per Softwareverteilung und nicht über den WSUS machen, bisher werden die Clients nur auf Anfrage des jeweiligen Benutzers manuell auf die jeweils neueste Version gebracht. Grüsse Gulp

OK, die Retail EULA gibt das auch nach mehrfachem Lesen so aus meiner Sicht zwar nicht nicht wirklich her, da sind die PUR dann doch deutlicher ..... Besten Dank! Grüsse Gulp

Exakt, die Hardware wird lizenziert, deswegen muss ja für jede weitere VM auch eine für das gesamte Blech passende Lizenz verwendet werden, das sagt die EULA ja auch aus. Lassen wir die detaillierte Core Lizenzierung mal kurz auf die Seite treten und sagen wir ich kaufe 2 für das Blech passende 2016 Standard Lizenzen, dann kann ich beide dem Blech zuweisen und beispielweise unter einem Linux Hypervisor auch als VM betreiben. Nutze ich als Hypervisor nun aber den Windows 2016 Standard, dann räumt mir Microsoft eine quasi kostenlose zusätzliche Instanz ein und die physikalische Instanz darf nur noch als Hypervisor laufen. Da sehe ich nirgendwo einen Hinweis darauf, dass ich diese zweite Lizenz nicht als zusätzliche VM dort betreiben dürfte. Will heissen, will ich bei Standard mehr als 2 OSE's betreiben muss ich beginnend mit der dritten für jede weitere VM das Blech mit einer passenden Lizenz bestücken. Grüsse Gulp

Das ändert nichts an der Tatsache, dass er bei Standard immer nur 2 OSE's virtuell installieren darf mit der einen Lizenz, egal ob 2012R2 oder 2016 und die 2 bekommst Du jeweils nur, wenn der Host in der jeweiligen Version läuft. Er will hier ja 4 OSE's laufen lassen, die 2 zusätzlichen musst man dann immer einzeln lizenzieren. Warum sollte das nicht gehen? Steht doch in der EULA unter Use Rights, 2 d iii: iii. If you want to run additional instances of the server software as set forth in this Section 2.d.i and 2.d.ii, you need to re-license the server as described in Section 2.b. https://www.microsoft.com/en-us/UseTerms/Retail/WindowsServer2016/DatacenterAndStandard/UseTerms_Retail_WindowsServer2016_DatacenterAndStandard_English.htm Das geht an sich, ist halt nur nicht ganz so billig ..... Grüsse 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