NilsK

Moin, ah, OK. Ja, dann passt's. ;) Gruß, Nils

Moin, wenn du mit ADFS anfangen willst, lass den Proxy weg. Den kannst du in einem Testaufbau ohnehin kaum sinnvoll nutzen. Und er bringt überhaupt keinen Erkenntnisgewinn für die eigentliche Technik - man installiert ihn und gut. Zu konfigurieren gibt es da praktisch nix. In der Praxis braucht man ihn sowieso nicht unbedingt, weil er eigentlich nur ein Reverse Proxy ist, den man auch über ein anderes System (z.B. Netscaler) abbilden kann. Außerdem solltest du die Rollen trennen. ADFS installiert man nicht direkt auf einem DC. Möglich, dass dort auch dein Problem liegt. Sinnvoller Aufbau fürs Lab: DC ADFS-Server ADFS-Testapplikation Für Letzteres empfehle ich dies - ist aber leider auch ein wenig holprig: [Test-Applikation für ADFS | faq-o-matic.net] http://www.faq-o-matic.net/2015/08/19/test-applikation-fuer-adfs/ Sonst baue ich Testlabs auch gern mit einem Testzugang für Salesforce, den gibt es kostenlos. Salesforce hat eine ziemlich gut gemachte SAML-Einbindung, die man hervorragend mit ADFS verbinden kann. Und: Auch das Testlab von vornherein richtig planen und aufbauen. Gerade das mit den Zertifikaten will gut überlegt sein: Das Service-Communication-Zertifikat ist ein TLS-Zertifikat auf den öffentlichen Namen der ADFS-Instanz, der damit vorher feststehen muss. Wenn man hier mit selbsterstellten Zertifikaten arbeiten will, muss man einigen Aufwand treiben, damit die Clients das hinterher auch nutzen können. Daher kann es sinnvoll sein, sich auch für das Lab ein "echtes" Zertifikat zu besorgen. Gruß, Nils

Moin, es gibt im Recht ein "Analogieverbot", das gerade vor allzu frei herbeigedachten Verbindungen schützt. Ein Urteil, das sich auf einen Fall bezieht, lässt sich nicht einfach so auf irgendwelche anderen Fälle übertragen, die irgendwie mit dem Thema zusammenhängen. (So wollte mir mal jemand anhand eines Kochtopf-Kaufs herleiten, warum bestimmte Ansprüche eines Softwareherstellers ungültig seien - nee, eher nicht.) Es gibt auch kein allgemeines Lizenzierungs-Recht mit übergeordneten Grundsätzen, sondern es handelt sich bei Lizenzverträgen um Verträge, die zwischen zwei Parteien ausgehandelt werden. Es gibt in unserer Rechtsordnung eine sehr weitreichende Vertragsfreiheit, in der z.B. ein Lizenzgeber viele Definitionsmöglichkeiten hat, an welche Bedingungen er die Lizenzvergabe knüpft. In der Vergangenheit haben sich Fälle wie der, um den es hier geht, fast immer als Betrug herausgestellt. Daher mein Hinweis. Wie Franz und andere schon richtig sagen: Mit solchen Hinweisen bzw. Einschätzungen endet das, was wir hier legal und sinnvoll sagen können und dürfen. Gruß, Nils

Moin, wieso? Nur weil SQL Server nach Linux portiert wird, wird er ja noch lange nicht Open Source. Und von kostenlos hat Microsoft auch nirgends was geschrieben. Wenn man SAP auf Linux betreibt, ist es ja auch nicht kostenlos (und meines Wissens auch nicht günstiger als auf anderen Plattformen). Gruß, Nils

Moin, in welchem Gesetz soll stehen, dass Daten im Normalbetrieb "sicher" gelöscht (also überschrieben) werden müssen? Das wäre mir zumindest neu - und da in dem Bereich auch ziemlich viele Missverständnisse kolportiert werden, darf man das skeptisch sehen. Die einschlägigen Hinweise von Datenschützern beziehen sich i.d.R. auf Datenträger, die außer Betrieb genommen werden, nicht auf solche, die sich in normaler Benutzung befinden. Würde das Betriebssystem im Normalbetrie pauschal Daten durch Überschreiben löschen, dann ginge die Leistung eines Dateiservers brutal in die Knie. Er wäre vermutlich kaum noch benutzbar. Darüber hinaus würde das ja nicht ausreichen, denn auch das normale Ersetzen von Daten müsste erweitert werden - überschreibt eine Anwendung vorhandene Daten durch neue Daten, die weniger Platz einnehmen, müsste sie den Rest dann ja auch noch überschreiben. Ich wage zu bezweifeln, dass es Standard-Betriebssysteme gibt, die sowas machen. Also wie immer: Die Anforderungen sind zu klären und zu prüfen. Und umsonst gibt es nur wenig. Wenn also kein Budget für eine Lösung bereitsteht, dann kann das Problem nicht wichtig sein. Gruß, Nils

Moin, das ist aber bestenfalls ein Verschleiern. Sicher ist das keineswegs. Eine sichere Lösung wird man auf dem Weg überhaupt nicht hinbekommen. Sofern die Applikation selbst die Angabe des Kennworts im Klartext erfordert, ist genau das das Sicherheitsproblem. Gruß, Nils

Moin, wenn die IT-Administration eine Abbildung der formellen Hierarchie in Gruppen benötigt, kann man das so machen. In dem Fall per Verschachtelung, also der Teil nach dem "oder" in deiner Frage. Tatsächlich ist das aber nur selten nötig, zumindest als vollständige Abbildung. Die IT-Administration hat meist andere Ansätze als das Organigramm. Das lässt sich meist über ein Rollenkonzept am besten lösen. Eine reine Abbildung der Hierarchien könnte man über das "Manager"-Feld hinbekommen. Auch da muss man aber prüfen, ob man das im AD überhaupt braucht. Gruß, Nils

Moin, nein, hatte ich noch nicht. Ist aber ziemlich eindeutig rechtswidrig - ein per Mail versandter Key ist keine gültige Lizenz. Gruß, Nils

Moin, ein vorgelagertes SSD-Caching kennt Hyper-V mit Bordmitteln nicht. Das müsste also eine Hardwarelösung liefern. Wahrscheinlich wäre es insgesamt günstiger, ein neues Storage zu nehmen, das von sich aus die Leistung bringt. (Und bevor jetzt jemand mit Vergleichen kommt: Trivial ist das in vSphere auch nicht.) Es wäre allerdings ggf. zu prüfen, ob wirklich das Storage selbst den Flaschenhals bildet oder die iSCSI-Anbindung. Ich hatte neulich einen Kunden, der ein 10-GbE-Storage mit 1 GbE angebunden hat - da liegt der Engpass dann im Netzwerk. Denkbar wäre, einen Windows-basierten Scale-out Fileserver vorzuschalten, der das bestehende Storage als "langsamen" Tier anspricht und einen SSD-Tier selbst einfügt. Auch das wäre aber teuer und komplex, und es kann auch sein, dass das mit dem vorhandenen Storage nicht geht. Gruß, Nils

Moin, die Diskussion haben wir hier (und anderswo) schon sehr oft geführt, wir sollten das hier nicht wiederholen. Ein Beispiel ist der oben bereits genannte Thread. Was ich mit meinem Einwurf meinte, ist, dass man es nicht unbedingt selbst in der Hand hat, ob man auf WINS verzichten kann. Es kann durch Applikationen oder Arbeitsweisen nötig werden. Alles Weitere siehe an den erwähnten Stellen. Gruß, Nils PS. eine Ergänzung noch: Jehova, Jehova ...

Moin, da ist Wahres dran - aber ich würde es noch ergänzen um: Ob du WINS brauchst, hängt davon ab, wonach die Clients fragen. Wenn die irgendwas machen wollen oder sollen, was Auflösung von kurzen Namen beinhaltet, dann ist WINS auch heute noch die eleganteste Lösung. Gruß, Nils

Moin, ein EV-Zertifikat ist vom Ablauf her etwas aufwändiger. Richtig teuer ist es auch nicht. Gruß, Nils

Moin, die nötigen Kenntnisse kannst du dir mit Hyper-V auch kostenlos aneignen. Und den Betrieb danach kannst du ebenso ohne Lizenzkosten durchführen. So richtig stichhaltig ist das Argument daher nicht. Und komplex ist KVM auch. Gruß, Nils

Moin, wie die anderen schon sagen: Installier dir ein Laborsystem mit der 180-Tage-Eval von Windows Server 2012 R2 und mach dich erst mal mit Hyper-V vertraut. Wenn du nebenbei noch mit der Core-Version kämpfen musst, lenkt das nur vom Wesentlichen ab. Erst wenn du mit dem Grundsystem sattelfest bist, solltest du dich an eine Core-Instanz wagen. Für den produktiven Betrieb könnte dann der 5Nine Manager interessant sein, der auch Core-Hosts verwaltet. Kostet aber ein wenig. Wie du ja schon feststellst, hat gerade bei der Core-Verwaltung die Domänenmitgliedschaft der Hosts große Vorteile. Das solltest du dann also so einrichten. Client-Betriebssysteme darfst du nur virtuell betreiben, wenn du entweder die Enterprise Edition oder eine zusätzliche VDI-Zugriffslizenz hast. Gruß, Nils

Moin, ich habe das hier mal diskutiert: [sSL für alle: Let’s Encrypt geht den nächsten Schritt | faq-o-matic.net] http://www.faq-o-matic.net/2015/12/09/ssl-fr-alle-lets-encrypt-geht-den-nchsten-schritt/ Vor Let's Encrypt hat man übrigens keine 30-Tage-Intervalle gehabt. Das typische "SSL-Zertifikat" war ein Jahr gültig. Die kurzen Laufzeiten sind ein Novum, das Let's Encrypt erst eingeführt hat. Gruß, Nils

Moin, prima, danke für die Rückmeldung! Gruß, Nils

oh ja ... :D

Moin, nein, eure Gegend heißt Brandenburg, glaub ich. :D Gruß, Nils

Moin, um das kurz zu sortieren: Die Änderung in dem Artikel beschreibt, wie man den Assistenten von dsa.msc (AD-Benutzer und -Computer) dazu bringt, den Objektnamen (und displayName) als "Nachname, Vorname" zu erzeugen.Damit funktioniert das nur, wenn man User neu über diesen Assistenten erzeugt. Sofern man in Exchange eine neue Mailbox einem bestehenden User zuweist, bleibt der bestehende Name erhalten. Ist dieser als "Nachname, Vorname" angelegt, taucht er auch in Exchange usw. so auf. Legt man eine neue Mailbox für einen neu zu erzeugenden User in Exchange an, dann greifen die Vorgaben für den dsa.msc-Assistenten nicht. Hier gibt es keine (bekannte) Möglichkeit, das gewünschte Format vorzugeben. Beim Anlegen von Usern per Skript oder Kommandozeile gelten die Vorgaben für den dsa.msc-Assistenten ebenfalls nicht. Hier kann bzw. muss man das im Kommando selbst angeben. Um das Format für bereits bestehende AD-User zu ändern, eignet sich z.B. dies: [Wie kann ich meine Benutzer als "Nachname, Vorname" anzeigen? | faq-o-matic.net] http://www.faq-o-matic.net/2003/08/10/wie-kann-ich-meine-benutzer-als-nachname-vorname-anzeigen/ Gruß, Nils

<aufstampf /> :D

Moin, Jungs, könnt ihr bitte mal, jeder für sich, kurz vor die Tür gehen und ein wenig frische Luft schnappen? Eure Diskussion hat nichts mit dem Thema des Threads zu tun und ist darüber hinaus nicht mal mehr interessant. Niemand muss hier die Marketingschlachten der Hersteller weiter schlagen. Das verdirbt nur die Stimmung (wofür es in eurer Diskussion schon deutliche Anzeichen gibt). Gruß, Nils

Moin, möglich, aber davon redet er hier gar nicht. Ja, das ist die typische NetApp-Argumentation. Habe ich auch jahrelang behauptet. Und die immanenten Nachteile gegenüber einer sauberen Trennung beider Ansätze (Performance, Komplexität, Funktionsverluste) geflissentlich vom Tisch gewischt. Und das ist der wichtigste Satz in deinem Beitrag. Gruß, Nils

Moin, da differieren unsere Ansichten ja nicht. Ziemlich genau das meinte ich. Es geht aber eben nicht mit Bordmitteln, und es besteht ein Unterschied zwischen dem üblichen Verständnis von HA und dem von FT. Gruß, Nils

Moin, jaja, das alte Missverständnis, dass man Live Migration auch dann erwartet, wenn ein Host ausfällt. Kann nicht gehen. In keiner Hypervisor-Welt. Man sollte auch beachten, dass Hochverfügbarkeit (HA) nicht dasselbe ist wie Fault Tolerance (FT). FT kann Hyper-V nicht ohne Zusatztools. In vSphere geht das (abhängig von der Lizenz), wird aber in der Praxis so gut wie nie eingesetzt, weil die Einschränkungen in den meisten Szenarien zu umfassend sind. Gruß, Nils

Moin, Storage Live Migration kann Hyper-V auch nativ, SCVMM braucht man dafür nicht. In 2012 R2 auf jeden Fall, in 2012 glaube ich auch. Das geht dann ohne Downtime für die VMs. Auch cluster-übergreifend (nennt sich dann "Shared-Nothing Live Migration"). Gruß, Nils