Alle Aktivitäten

Ich ergänze bzw. war noch bei "allen" hier gelisteten M365 Lizenzen, die entsprechende CALs beinhalten: Microsoft Product Terms

Nicht in den Business Plänen. Zumindest hab ich das noch nirgends herausgelesen. Die aber ganz klar, _nur_ noch fürs Recipient Management genutzt werden darf und nicht mal mehr als lokales Hybrid SMTP Gateway. Heißt, wer den Hybrid Server als SMTP Gateway nutzt (auch ohne Mailbox) begeht also einen Lizenzverstoß, bzw. bedeutet das im Umkehrschluss, dass man dann auch auf die Hybrid Lizenz verzichten kann, denn niemand installiert ja zwei Server (einen für SMTP und einem fürs Recipient Management).

Mein aktueller Stand ist: M365 Lizenzen aus dem CSP (MCA) beinhalten die erforderlichen Exchange CALs, nicht jedoch die Exchange Server-Lizenz selbst. Für die lokale Installation wird daher eine Exchange Server Lizenz mit aktiver SA benötigt – z. B. über Open Value. In Kombination mit den M365-Plänen (inkl. Exchange Online + CAL-Äquivalents) kann damit auch die kostenlose Hybrid-Lizenz genutzt werden, sofern die Voraussetzungen erfüllt sind. Heißt konkret: M365 + Exchange Server Lic/SA = vollständiges Nutzungsrecht für lokale Exchange-Installationen.

Am Ende aber eine "spannende" bzw. genau die Diskussion, die nirgends wirklich geführt wird. Du hast ja selber geschrieben, dass die Fragen in der Tech Community unbeantwortet bleiben. Ebenfalls sehe ich das auf LinkedIn. Da wird viel von (bspw.) Scott Schnoll in die Lizenzierungsrichtung kommentiert aber nirgends mit den Infos, die es jetzt hier gibt. Jetzt kam mir zu einem anderen Punkt hier in der Diskussion gerade noch eine Idee: In den M365 Lizenzen aus dem CSP (MCA) ist der Exchange SE nicht inkludiert Die CALs wiederum sind in allen M365 Lizenzen inkludiert und benötigen in diesem Fall keine SA Sobald ich Exchange online lizenziert habe, darf ich einen kostenlosen Exchange (muss neuerdings aktive SA haben) für eine Hybrid Bereitstellung nutzen, sofern dort keine Mailboxen liegen. Liegen dort Mailboxen brauche ich CALs, die ich wiederum durch die M365 Lizenzen habe. Brauche ich also mit den entsprechenden M365 Plänen, die eine Exchange CAL inkludiert haben nur eine SA für Exchange SE nachlizenzieren und kann dann die kostenlose Hybrid Lizenz nutzen? 🧐

Das steht doch auch in dem von mir zitierten und verlinkten Blogpost hier drin, dass wenn man Exchange 2019 + CALs jeweils mit SA hat ist man für SE "sauber", man muss halt nur die SA aktiv halten, wenn die 3 Jahre dann rum sind. Das war ja auch deren Empfehlung für Kunden, die keine Cloud Lizenz haben, bevor der SE veröffentlicht wurde und man direkt dessen Lizenzen erwerben konnte. PS: Da habe ich ja eine Diskussion losgetreten, warum muss das bei MS so kompliziert sein.

Versteh das Szenario grad nicht. Dann darf er mit Erscheinen von SE automatisch SE installieren und einsetzen und vorausgesetzt auch seine CALs haben SA, dürfen auch seine User einfach zugreifen. Stand das irgendwo schonmal zur Frage, oder ging es hier jetzt um das Kauf- Mietlizenz? Was ja eh eher Augenwischerei ist, denn auch die SA war ja quasi schon ne Miete.

Naja ganz ehrlich, das ist auch nur ein Zugeständnis an Kunden die sowas schon haben und kein Goodie für Kleinkunden die um das halbe Jahr noch Support brauchen.

Hi zusammen, Ihr macht mich unsicher...smile*** Deswegen hab ich mal extrem kompetente "Quellen" dazu angefragt um einen klaren Blick zu erhalten. Was ist mit einem Kunden, der im Januar im OPEN-VALUE oder MPSA(SELECT) oder EA frisch 1 Exhange-SVR 2019 mit 3 Jahren SA gekauft hatte? Was gibt ihm die teuer bezahlte SA ( heißt ja SA = vertaglich zugesicherter Anspruch auf den Nachfolger, wenn dieser in diesen 3 Jahren der SA erscheint) . Was sagt MS dazu? Aus Kauflizenz eine Miet-Lizenz machen? Rechtlich sehr fraglich! Habe auch keinen "Migrationspfad" dazu im WEB gefunden. mal abwarten was meine "Quellen" dazu sagen. Sorry für die Unsicherheit. Grüße, Franz

Hi zusammen, zu Auditoren sag ich lieber fast nix, früher gab es mal wirklich gute und im Lizenzrecht fitte, aber die sind wohl alle wech.... smile* Und da fast die meisten Kunden unsicher im Lizenzieren sind, wird von den Auditoren machmal auch sehr fragliches gesagt, das sich nicht in den vertägen oder PURs wiederspiegelt! Nochmals zu Office und TS-Dienst. Legal ist es auch aus bestimmten gründen noch lokal auf dem PC/NB ein Office-STD 2003 obwohl auf dem TS ein 2010-PRO installiert ist ! auch wenn ich im Netzwerk aktiv mich befinde, aber nie die 2010-Pro auf dem TS nutze, brauche ich nur die 2003-STD lokal zu lizenzieren...sind so die Feinheiten. smile* Zum Thema gebrauchte Lizenzen: Wenn es sich um Volumen-Lizenzen handelt, alles legal und sauber und Microsoft nickt das positiv ab, wenn... schriftliche Dokumentation existiert: Transfer of Licence: Verkäufer /Käufer aus welcher Volumenvertrags-Nummer, genaue Produktbezeichnung und Anzahl (am besten die MS-SKU-Nr., da eindeutig) Dann auch die Bestätigung im Doku, dass die verkauftenb Lizenzen gelöscht worden ! z.B. Vendosoft, oder die U-S-C kenne ich als sauber gebraucht-Partner, die auch viel mit MS zusammenarbeiten !!! sind nur Beispiele. Hoffe, ich hab nix vergessen, Viele Grüße, Franz

Hi, in den Kommentaren ist es direkt spannend.. Klingt irgendwie nach einer "tollen" Ankündigung und es weiß noch niemand was und wie es passiert. Gruß Jan

Microsoft hat gestern angekündigt, ab 1.8. ein ESU für Exchange 2016 und Exchange 2019 anzubieten. Vorgesehen ist das für Kunden, welche die Migration nicht bis zum 14.10.2025 abschließen können werden. Die Laufzeit ist auf 6 Monate begrenzt und endet endgültig am 14.4.2026. Abhängig vom Preis kann man sich also noch ein halbes Jahr Zeit "erkaufen". Aus MS Sicht dürfte das Risiko überschaubar bleiben, wenn man sich deren ganze Einschränkungen anschaut. Keine garantierten SU während der Laufzeit und da sich Exchange SE und 2019 bis dahin sowieso nicht wirklich unterscheiden wäre die Arbeit für MS so oder so angefallen. Weitere Infos hier: https://techcommunity.microsoft.com/blog/exchange/announcing-exchange-2016--2019-extended-security-update-program/4433495

Hier hat @lizenzdoc etwas zu gebrauchten Lizenzen geschrieben: https://www.mcseboard.de/topic/229404-vendosoft-erfahrung-gebrauchtsoftware/#findComment-1472281

Wir haben mit der Konfiguration MaxOfflineTimeLimit für den Dienst Netlogon herumexperimentiert und auch via GPO konfiguriert, dass auf das Netzwerk gewartet werden soll. Die Startzeit verlängert sich minimal vom System, aber der Fehler wird weiterhin protokolliert.

Wenn du Volumenlizenzverträge hast, steht dort üblicherweise auch das Audit Recht drin, welches du MS einräumst. Hab aber schon länger nicht mehr nachgeschaut und auch selbst schon länger kein Audit mehr bemerkt bei meinen Kunden.

Und was ist eine "entpsrechende" Beziehung? Wird es interessant oder eher ungemütlich?

Genau das. ;) natürlich ist eine entsprechende Vertragsbeziehung notwendig. das wird dann erstmal interessant. :)

Hey, gestattet bitte ein paar Nachfragen dazu von mir, 1.) Wann ist so ein Audit bzw. was ist der Trigger der so ein Audit auslöst? Oder ist das Zufall und Microsoft pickt sich einfach irgendwelche Unternehmen raus? 2.) Was sagen die im Audit zu legal erworbenen gebrauchten Lizenzen?

Der KMS ist ja auch nicht für die Lizenznutzung zuständig, sondern einzig und allein diverse Produkte zu aktivieren. Hinsichtlich der Werkzeuge stimme ich dir zu.

Der Witz dabei ist, das MS, zumindest beim KMS, weder die Lizenz-Nutzung irgendwie sinnvoll protokolliert noch irgendwelche anderen Werkzeuge an die Hand gibt, um ein verlässliches Reporting zu erzeugen. Wenn MS einen Prüfer beauftragt geht der nach seinem Schema vor. Möglicherweise verlangt er dann einen Nachweis, dass der User Office nie gestartet hat. Dem kann der Geprüfte selten nachkommen. Der Prüfer wird den dann trotzdem als Lizenz zählen und wir wären im Bereich der Haarspalterei oder irgendwelcher Rechtsstreite.

Hallo zusammen, wir vernehmen auf diversen Windows 11 24H2-Systemen, die entweder frisch(!) installiert oder via Inplace-Upgrade aktualisiert wurden, den Fehler NETLOGON 5719 auf. Allerdings konnten keine Einschränkungen (Zugriff Freigaben, freigegebene Drucker, RDP-Zugriff auf Terminalserver, usw) festgestellt werden. Konnte jemand schon ähnliches feststellen und hat ggf. eine Lösung dafür parat? Ein Netlogon.log habe ich bereits erstellt. Ausschnitt daraus mit Schwärzungen: 07/16 10:01:36 [CRITICAL] [5976] C:\WINDOWS\system32\config\dclocadminmappings.log: Unable to open. 2 07/16 10:01:36 [CRITICAL] [5976] C:\WINDOWS\system32\config\dclocscanmappings.log: Unable to open. 2 [...] 07/16 10:01:36 [CRITICAL] [5976] C:\WINDOWS\system32\config\netlogon.ftj: Unable to open. 2 07/16 10:01:36 [INIT] [5976] Getting cached trusted domain list from binary file. [...] 07/16 10:01:36 [CRITICAL] [5976] NlCacheJoinDomainControllerInfo: Failed to open JoinDomain breadcrumb in registry; assuming 07/16 10:01:36 [CRITICAL] [5976] NlCacheJoinDomainControllerInfo: therefore that this is not a post-join scenario. 07/16 10:01:36 [CRITICAL] [5976] NetpDcGetName: NlCacheJoinDomainControllerInfo returned success [...] 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSessionSetup: Denied access as we could not authenticate with Kerberos 0xC002002E 07/16 10:01:37 [CRITICAL] [5976] Assertion failed: ClientSession->CsState == CS_IDLE (Source File: onecore\ds\netapi\svcdlls\logonsrv\server\lsrvutil.c, line 3981) 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSessionSetup: Denied access as we could not authenticate with Kerberos (translated status) 0xC00000E5 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSetStatusClientSession: Set connection status to c00000e5 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSetStatusClientSession: Unbind from server \\test1-dc01.TEST-dom.local (TCP) 0. 07/16 10:01:37 [MISC] [5976] Eventlog: 5719 (1) "TEST-DOM" 0xc00000e5 3dc54378 84808124 847d677c e2aadc59 xC.=$...|g}.Y... 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSetStatusClientSession: Set connection status to c000005e 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSessionSetup: Session setup Failed 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSessionSetup: Try Session setup 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlDiscoverDc: Start Synchronous Discovery 07/16 10:01:37 [MISC] [5976] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c3fffff1 07/16 10:01:37 [MAILSLOT] [5976] NetpDcPingListIp: TEST-dom.local.: Sending UDP ping to 10.1.0.100 07/16 10:01:37 [ERROR] [1608] NlpGenerateIumBoundMachineAuthCert: Provisioning interface not responding; treating as if IUM weren't available: 1717 07/16 10:01:37 [MISC] [1608] NlpStoreKeyInDS: IUM Provisioning interface not up. 07/16 10:01:37 [ERROR] [1608] NlpStoreKeyInDS: No machine bound certificate could be created: 1717 07/16 10:01:37 [ERROR] [1608] NlProvisionMachineAuthKey: Unable to store auth key in DS: 1717 07/16 10:01:37 [MISC] [5976] NetpDcAllocateCacheEntry: new entry 0x0000023BF11CC7D0 -> DC:test1-DC01 DnsDomName:TEST-dom.local Flags:0x3f1fc 07/16 10:01:37 [MISC] [5976] NetpDcGetName: NetpDcGetNameIp for TEST-dom.local. returned 0 07/16 10:01:37 [MISC] [5976] NetpDcDerefCacheEntry: destroying entry 0x0000023BF1673240 07/16 10:01:37 [MISC] [5976] LoadBalanceDebug (Flags: FORCE DSP AVOIDSELF ): DC=test1-DC01, SrvCount=1, FailedAQueryCount=0, DcsPinged=1, LoopIndex=0 07/16 10:01:37 [PERF] [5976] NlSetServerClientSession: Not changing connection (0000023BF16B9168): "\\test1-dc01.TEST-dom.local" ClientSession: 0000023BF1672530TEST-DOM: NlDiscoverDc: Found DC \\test1-dc01.TEST-dom.local 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSessionSetup: Negotiated flags with server are 0x612fffff 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSetStatusClientSession: Set connection status to 0 07/16 10:01:37 [DOMAIN] [5976] Setting LSA NetbiosDomain: TEST-DOM DnsDomain: TEST-dom.local. DnsTree: TEST-dom.local. DomainGuid:a218299c-ed14-47f8-9397-f8f4b3d48e24 07/16 10:01:37 [LOGON] [5976] NlSetForestTrustList: New trusted domain list: 07/16 10:01:37 [LOGON] [5976] 0: TEST-DOM TEST-dom.local (NT 5) (Forest Tree Root) (Primary Domain) (Native) 07/16 10:01:37 [LOGON] [5976] Dom Guid: a218299c-ed14-47f8-9397-f8f4b3d48e24 07/16 10:01:37 [LOGON] [5976] Dom Sid: S-1-5-21-1659004503-1935655697-1343024091 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSetStatusClientSession: Set connection status to 0 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSessionSetup: negotiated 612fffff flags rather than 0 07/16 10:01:37 [SESSION] [5976] TEST-DOM: NlSessionSetup: Session setup Succeeded 07/16 10:01:37 [INIT] [5976] Started successfully ach, kurzer Nachtrag: Als Fehlermeldung wird "Interner Fehler." ausgegeben in der Ereignisanzeige.

@lizenzdoc Ich hätte das gerne wenigstens EINMAL IM LEBEN so von einem Auditor gehört. Es war IMMER "Fähigkeit zu starten ohne vorher zusätzliche technische Maßnahmen ergreifen zu müssen". Vielleicht waren sie alle Oracle-verseucht, was weiß ich. Als Alternative wurde oft ein SAM-Produkt mit lückenlosem Software-Metering ins Gespräch gebracht, worauf dann natürlich wieder Betriebsräte allergisch reagieren. Als Techniker leuchtet es mir auch total ein - das Unternehmen unterschreibt, dass von den vorhandenen 10.000 Endgeräten nur 2.500 Office-Programme nutzen, obwohl von allen 10.000 aus eine Terminalserver-Farm mit installiertem Office erreichbar ist. Wie kann diese Aussage aber auf nichtpersistenten Terminalservern validiert werden? Vielleicht waren's ja nur 500 Geräte und es gibt Geld zurück?

Und wer mehr Zeit braucht darf auch gern Exchange ESU kaufen. ;) Man kann schließlich auch mit dem alten Produkt noch Geld verdienen: https://techcommunity.microsoft.com/blog/exchange/announcing-exchange-2016--2019-extended-security-update-program/4433495 6 Monate zwar nur, aber immerhin kein Aufwand für MS, denn solange Exchange 2019 und SE sowieso codeidentisch sind, kann man beide in einem Rutsch fixen und vermutlich unterscheidet sich Exchange 2016 und 2019/SE auch nicht so riesig voneinander an den meist betroffenen CAS Teilen. ;)

In virtuellen Umgebung war die SA nicht zwingend optional. Stichwort wäre hier (AFAIK) "License mobility". Eine andere Option wäre (AFAIK) gewesen, jeden physischen Server im Cluster mit der passenden Exchange Server Lizenz auszustatten. Das Zitat (vermutlich aus der Tech Community zu einem der Exchange SE Blog Beiträge) ist erstmal korrekt aber wohl kein "rechtsverbindliches" Dokument bzgl. Lizenzierung. Das sind stand jetzt die Product Terms (Microsoft Product Terms), in denen es noch keinen Exchange SE oder diesen Passus gibt. Jedenfalls finde ich nichts in die Richtung.

Moin an Board, habe heute mal etwas länger geschlafen, koche noch eben schnell Kaffee Bergfest! Allen einen guten Mottwoch, bleibt gesund! Wetter muss ich nachliefern, auf jeden Fall aktuell Regen War laut gestern Abend, Iron Maiden waren Open Air auf der Bürgerweide

Ich möchte dir nur sehr ungern widersprechen, da du mit ziemlicher Sicherheit mehr Ahnung von der MS-Lizenzierung hast als ich. Aber in den Informationen zum Upgrade steht das anders. Da steht explizit: Mal abgesehen davon, dass die den Fall mit E3 Lizenzen ohne "Extended Use Right" dort nicht erwähnen würde das ja trotzdem bedeuten, dass ich für den Server SA brauche. Das ist ja gerade der große Unterschied zu früher, wo SA optional war. Ist dann nach meinem Verständnis vergleichbar mit den Core Lizenzen für den SQL-Server, da brauche ich ja auch zwingend SA, um den benutzen zu dürfen.