m0insen

Hallo Salim, ich kann dir hier gerne von meiner Erfahrung berichten: Nach einem konzernweiten, "unfreundlichen" Microsoft-Audit in 2014 habe ich den gesamten Lizenzstock, beginnend bei MSFT konsolidiert und zentralisiert und dabei auch ein SAM Tool (Shortlist waren flexera und Matrix42, es wurde dann Matrix42) eingeführt. In 2020 habe ich die Wartung von Matrix42 SAM auslaufen lassen und wir nutzen inzwischen für Microsoft, VMWare, Autodesk, Solidline, SAP usw. ... Excel! Warum? Der Großteil der Lizenzen ist inzwischen named-user. Das klassische Lizenz + Wartung mit Wartungsverlängerung usw. nimmt stetig ab. Die SAM Tools können eine Hilfe sein, der konstante Pflegeaufwand ist aber in größeren Umgebungen (~5000 Endgeräte, ~1000 Server) massiv. Ich nutze inzwischen das Geld, was ich für das SAM-Tool inklusive Betrieb verwendet habe, um eine Vollzeit-Sachbearbeiter-Stelle zu finanzieren (und spare dabei noch). Hat sich für mich so ergeben und ich bin zufrieden damit. Wenn ich heute ein SAM Projekt starten würde, dann nur als übergreifendes IT-Asset-Management Projekt, also inklusive aller Leasing-/Kauf-Whatever-Hardware. Grüße

Niemand? Ich hab am Wochenende noch alle mir bekannten LAR etc. angeschrieben, auch da ernte ich nur Schulterzucken. Es gibt Gerüchte, Microsoft würde ab 01.01. die WinSrv2008 ESU via CSP anbieten, aber selbst die CSP haben da was konkretes oder greifbares, nichtmal internes Material... Sollte jemand von euch etwas hören - ich wäre sehr dankbar.

Hallo, ich bin auf verzweifelter Suche nach nem Strohhalm... kennt jemand irgendeine Möglichkeit, an ESU Schlüssel für Windows 2008 R2 Server mit aktiver SA zu kommen, ohne EA? Virtualisierung und hochpumpen nach Azure ist leider keine Option. Kosten wären mir egal. Hiiiilfe! ?

Moin zusammen, Nach den „Online Service Terms“ gibt es da wenig zu diskutieren. Alle O365 Lizenzen sind named user basiert. Möchtest du in der Produktion O365 einsetzen musst du das gesamte Personal mit jeweils einer Lizenz ausstatten - vollkommen unabhängig von der Geräteanzahl/-basis. Das klassische Office FPP ist gerätebasiert. Das ist in vielen Fällen ein Graus - in dem von dir genannten ist das ein Vorteil.

Ganz ehrlich: Ein EA zu verhandeln ist ein vielstufiger Prozess, entweder mit MS direkt oder über einen LAR als Vermittler. Viele deiner Fragen lassen sich im Prozess als Nebenabreden festlegen, wenn vom Kunden gewünscht. Der EA ist mehr oder minder ein klassischer Rahmvertrag zwischen MS und einem Großkunde - da geht fast alles. Gute Vorbereitung, aber das gehört auf den Verhandlungstisch. Grüße

Ganz einfach. Muttergesellschaft schließt MPSA ab. Alle Tochtergesellschaften (Besitz > 50%) dürfen Lizenzen nutzen. P.S. USA ist teuer, besser Südkorea oder Malaysia.

Ich versteh die Aufregung nicht: Alle Produkte die derzeit für "Lizenzmobilität innerhalb von Server Farmen" berechtigt sind (beschrieben in den PUR und unter aktiver SA), sind berechtigt an der [1 Satz vorher beschriebenen serverfarmübergreifenden] Lizenzmobilität durch SA teilzunehmen. Oder ohne Juristendeutsch: Serverapp mit aktiver SA berechtigt dich, die Lizenzmobilität nicht nur innerhalb von einer Hyper-V/VMWare Farm zu nutzen, sondern auch HA/DR via Azure/AWS und Co zu implementieren.

Hallo zusammen, eine Info für euch, die nur mittelbar mit Lizenzen zu tun hat: Solltet ihr grad einen Migrationspfad zu Windows 10 planen, solltet ihr den wundervollen Einfall von MSFT mit einbeziehen, dass alle Rechner mit Intel Skylake Architektur nur noch bis Juli 2017 mit Windows 7 Sicherheitsupdates versorgt werden. Ausgewählte Geräte werden anschließend noch "mit den wichtigsten Sicherheitsupdates" (wer immer das entscheiden mag) versorgt. Eine träge Migration über Jahre (z.B. Leasingaustausch), fällt daher wohl für die meisten flach. Grüße

Hallo Franz, hallo Weingeist, vielen Dank für eure Beiträge. Die Widersprüchlichkeit der Bedingungen werden dabei super herausgearbeitet. Ich werde mir den Spaß mal gönnen und versuchen, eine offizielle Antwort von MSFT zu erhalten. Sollte da was brauchbares bei rumkommen, geb ich euch bescheid. Grüße

Hallo Norbert, wir reden hier ja über Compliance/SAM. Und diesbzgl. muss halt bzgl. User CAL "Menschenaccount" vom "technischen Account" unterscheidbar sein.

Hallo J, wenn ein Mensch die vom Exchange zur Verfügung gestellten Dienste nutzt, ist dieser zu lizenzieren. Entweder pro Mensch (=User CAL), oder pro Gerätekette (=Device CAL). Grüße

Hallo Franz, ich recherchiere grad zu einem ähnlichen Problem, daher grabe ich diesen Fred mal aus. Ich halte deine Einschätzung mindestens für fragwürdig... Wenn Firma-A einen Volumenvertrag mit MSFT hat, wird hier klar geregelt, dass die von Firma-A gekauften Lizenzen nur für Tochter-/Schwesterfirmen genutzt werden dürfen, die zu >50% im Besitz von Firma-A sind. Dies ist im Beispiel nicht der Fall. Selbst wenn man (1) ignoriert, dürfte der Wirtschaftsprüfer von Firma-A bei der nächsten Prüfung dies nicht akzeptieren, da Firma-A keine Dienstleistungen (hier: IT-Infrastruktur) für Firma-B durchführen darf, ohne dass dafür eine Verrechnung stattfindet. Grüße

Ok, jetzt sind wir wirklich mitten im Thema "Wie organisiere ich einen konsistenten SAM Prozess in einem Unternehmen". Einer der ersten Schritte war zumindest bei uns damals die logische Trennung von Accounts innerhalb der Struktur des Verzeichnisdienstes. Also genau die Trennung von "Menschen-Accounts" und sonstigen Accounts. Ansonsten lässt sich ja überhaupt keine User-CAL Bilanz ziehen - weder im Bereich SharePoint, CRM, Windows Server, oder was auch immer.

Hallo Norbert, hallo Franz, Das ist über AD-OUs und Co relativ einfach technisch auswertbar. Was mir aber eben fehlt ist die Rückinfo aus dem Exchange System, welche AD-Accounts auf die Exchange Umgebung zugreifen. Die Exchange CAS sollten das durchaus wissen, lassen mich aber nicht teilhaben. Mag so klingen, aber die unbefriedigende Bilanz im SAM-Tool bzgl. Exchage CAL war ursächlich für mein Interesse. Ich hab auch erst unserem SAM Projektleiter, anschließend dem SAM-Tool Hersteller blöde Fragen gestellt, warum er keinen Connector zu Exchange anbietet und diese Infos auswertet. Als da nur Geschwurbel kam, hab ich in meinem Netzwerk rumgefragt: Auch die andere SAM Tools (Flexera usw.) tun sich da schwer. Darauf läuft es wohl hinaus, ist aber in dezentral organisierten Unternehmen ein ziemlicher Brocken an Aufwand. Wenn man das durchrechnet, ist eine Überlizenzierung bzgl. Exchange Standard CAL vermutlich günstiger als die Prozesskosten. Hehe, ja. Das ist wohl der feuchte Traum eines jeden SAM-Verantwortlichen. Daraus ließen sich Bedarfe aller Art ableiten, begründen und durchsetzen. Grüße Nachtrag: Spannende Idee, sowas im KVP zu integrieren... muss ich mal länger drüber nachdenken.

Hallo Franz, ja, das wär leider zu einfach. Hatte das eher modellhaft dargestellt, realistisch sind es 3500 Angestellte mit Windows-Netzwerk Zugriff, verteilt auf ~80 Firmen in ~50 Ländern. Ma eben "Employees - Nicht-Exchange-User" is also nicht, schon allein weil ich die exakten Zahlen in Takka-Tukka-Land nicht kenne. Es scheint ja wirklich kein sauberes Auswertungstool o.ä. zu geben (zumindest im 2010er) Umfeld. Sehr enttäuschend.

Hallo zusammen, ich finde keinen belastbaren Weg, die Menge von benötigten User CALs in einer Exchange 2010 Umgebung zu zählen. Folgendes Szenario: Ein Unternehmen mit 1500 Mitarbeitern nutzt eine Exchange 2010 Infrastruktur. Die Server lassen sich lizenztechnisch recht einfach kontrollieren, zusätzlich konnte mit ein paar Powershell Skripten sichergestellt werden, dass keinerlei Enterprise-Features auf Client-/Userseite im Einsatz sind. Bleibt die Frage nach der belastbar korrekten Zahl benötigter Standard User CALs. Wenn ich das richtig verstehe, sind folgende Dinge zu beachten: Angestellte dürfen mit einer User CAL mehrere Mailboxen nutzen (Anzahl Mailboxes == Anzahl User CAL ist also nicht). Ressourcenobjekte (Räume, Kalender, Public Folders, ..) benötigen keine CAL Ein Windows User (mit Windows Server User CAL) benötigt keine Exchange User CAL, wenn er wie Exchange Umgebung nicht nutzt (z.B. Produktionspersonal). Mir fehlt also ein belastbarer Ansatz, wie die benötigte Anzahl der "Exchange Standard User CAL" zu bestimmen ist. Hat das jemand von euch schon mal gelöst? Grüße

Hallo Franz, vielen Dank für die Antwort. Wenn du die SKU findest, würde ich mich freuen. In meiner derzeitig vorliegenden Liste taucht das nicht auf, schiebe das aber darauf, dass (Achtung: Gefährliches Halbwissen) dieses "Miet-AddOn" nur via MPSA buchbar ist und nicht via Select Plus. @kofferjunge: Wenn du Recht hast, gibt es zumindest die Möglichkeit, Office Standard (L/SA) wiederum via AddOn zu Office Pro Plus (L/SA) anzuheben. EA war mir in 2014 zu anstrengend, da für uns nur ein kombiniertes Paket EA und Select Plus in Frage kam und EA nur Office Pro Plus anbot. Da wir jeweils Teile der Core- & Enterprise CAL Suite nutzen und für uns keine entscheidenden Vorteile beim Windows Enterprise als Client OS fanden, waren irgendwie alle "drei Säulen" des EA nicht wirklich interessant, ergo hab ich das untern Tisch fallen lassen. Aber danke für den Tipp, da ich bis Juni vertragstechnisch eh handeln muss (Select Plus -> MPSA oder wie auch immer) werde mir morgen mal anschauen, was sich im EA Bereich in den letzten 1,5 Jahren getan hat. Grüße

Hallo zusammen, folgendes Szenario: Ein Unternehmen besitzt 1000 Microsoft Office Lizenzen mit aktiver Wartung, davon ~80% Standard, ~20% Professional Plus. Alle Lizenzen wurden über einen Select Plus Vertrag beschafft. Gibt es einen Pfad, wie diese Lizenzen zu Office 365 E3 Lizenzen gewandelt o.ä. werden können? Ich hab heute Vormittag auf diversen MSFT Seiten gesucht, aber rein gar nichts zum Thema gefunden. Die Antwort meines LAR/LSP war auch nicht besonders erhellend, es gäbe wohl die Möglichkeit, Office 365 E3 als Miet-Addon zu beschaffen. Genaueres kam aber nicht. Hat hier jemand Erfahrung mit diesem Thema? Grüße

Klasse Tool, dankeschön. PS: Sollten die Beispielpreise inkl. SA sein, würd ich gern heute noch mit dir verhandeln. ;-)

Hallo Daniel, genau auf Select(+)/EA Kunden beziehe ich mich doch - dies sollte auch durch den von mir gewählten Titel ausgedrückt werden. Ich versuche das noch mal auf uns zu konkretisieren: Status Quo: ~1500 Fatclients mit Win7/8/8.1 Pro OEM lizenz Alle Clients werden via Softwareverteilung mit Win 7 Pro betankt. Aktives Select Plus Agreement Fragestellung: Wie kann man das "kostenfreie" Upgradejahr in Richtung Win 10 Pro nutzen? Bisherige Meinung: Es ist notwendig, die Clients zuerst mit dem original OEM OS zu installieren, um diese anschließend auf Win 10 Pro zu aktualisieren (entweder WSUS oder Media Creation Toolkit) und dann aktivieren zu können. Wenn ich die oben genannten Quellen richtig verstehe, geht (jetzt) auch folgendes: Windows 10 Pro VL aus dem VLSC herunterladen, Clients mit Win 10 Pro via Softwareverteilung installieren, via KMS aktivieren. Ist das korrekt?

Nabend zusammen, ist jetzt doch wieder alles anders? Bevor ich hier nen Roman schreibe: https://community.spiceworks.com/topic/1238259-updates-to-deploying-the-windows-10-free-upgrade http://www.microsoftvolumelicensing.com/DocumentSearch.aspx?mode=1 Document Type: Windows 10 Ich hab den ersten Link jetzt zweimal gelesen und anschließend den Kommentar auf der Seite von LarryG. Oct 19, 2015 at 4:11 PM Wenn ich mich nicht komplett irre, ist jetzt folgender Fall (der für viele hier interessant sein dürfte), komplett ok: Unternehmen X besitzt einen haufen Clients mit Win7/8/8.1 Pro OEM Unternehmen X hat die unter (1) genannten Clients bisher via SW-Deplyoment mit Win7 Pro betankt Unternehmen X kauft eine Lizenz "Windows 10 Pro Upgrade VL" Unternehmen X kann seine unter (1) genannten Clients via SW-Deployment auf Win 10 Pro updaten ohne vorher Neuinstallation mit OEM OS -> Update -> Aktivierung durchführen zu müssen Was mir noch nicht klar ist: Wie läuft die Aktivierung? Kommentare? Grüße, Malte

Hallo Daniel, danke für die Ausführungen, das ist mir schon klar. Aus eben diesen Regeln erfolgt ja die Komplexität, die ich möglichst elegant und einfach zu lesen auch im AD abbilden möchte. Ich skizziere mal (modellhaft) eine Umgebung. Es gibt Den typischen Angestellten mit PC Zugriff <-- User CAL Den typischen Produktionsangestellten (Bsp: Logistikmitarbeiter). Dieser hat keinen individuellen Account, sondern teilt sich mit anderen ein Terminal, um Zugriff auf Aufträge zu haben <-- Device CAL Jetzt gibt es schon zwei Typen von User Objekten im AD, wobei ich die "Multi-User-Accounts" ja schon kennzeichnen und direkt sichtbar konkreten lizenzierten Device zuordnen möchte (z.B. in der Description oder über eigene OUs). Wir sind aber lang nicht fertig, sondern es gibt im AD noch jede Menge weitere Objekte vom Typ User... z.B. Service Accounts von Diensten Testaccounts von ITSM Mitarbeitern, um in bestimmte Berechtigungsrollen von Kunden schlüpfen zu können. administrative IT Accounts mit erhöhten Rechten temporär gesperrte Accounts, die aber nicht gelöscht werden dürfen (z.B. Mutterschutz) usw... Diese ganzen lizenzrechtlich wichtigen Unterschiede lassen sich in SAM Tools problemlos abbilden, bleiben dann aber im AD unsichtbar. Daher war/bin ich daran interessiert, wie andere ihr AD strukturieren... Grüße, Malte

Was zwingt dich denn zum Update (also jetzt rein aus Business Sicht)? Support für Win7 bekommst du noch bis Januar 2020...

Oha... also wenn du inplace updatest bleibten ja (theoretisch) die individuellen Einstellungen pro Rechner erhalten, beim anschließenden reinstall allerdings nicht. Sollten deine 300 Clients darüberhinaus wirklich komplett durchstandardisiert sein, du also 100% der jeweils installierten Software/Treiber/Konfigurationen via Softwaredeployment abdeckst... Respekt! :-) Noch ein drittes Argument: In deine Kostenrechnung solltest du auch noch 300x den Arbeitsausfall (Win7 -> Win10 -> Win7) bzw. deine Nacht-/Wochenendschichten, sowie die Ausfallzeit/Arbeitszeit für all die Fälle, in denen beim Inplace-Update mit anschließendem Reinstall irgendwas verloren gegangen ist einrechnen.

Hmm... klingt sinnig. ...passt bei uns leider nicht, dafür sind die einzelnen Standorte/Firmierungen zu unabhängig voneinander und ein reines MA = #User CALs funktioniert schon deshalb nicht, weil z.B. produktionnahe Mitarbeiter nur zum Teil Zugriff auf das Netzwerk haben. Trotzdem danke für das Feedback :)