NilsK

Moin, steuerlich und rechnerisch ist es in Deutschland i.W. genauso. Ein Dienstwagen mit Berechtigung zur Privatnutzung ist ein geldwerter Vorteil, der zu versteuern ist (nach Listenpreis des Wagens). Dazu kommt, dass auch die laufenden Kosten in so einem Modell üblicherweise anteilig mit dem Gehalt verrechnet werden - also in etwa "Nettozielgehalt minus Privatanteil an der Leasingrate ergibt zu überweisendes Nettogehalt". Wenn man das durchrechnet, lohnt es sich oftmals nicht, das muss man sich dann also überlegen. Was die Frage nach der Verhandlungsstrategie angeht - das ist eine persönliche Sache, die man bei Bedarf auch mit Coaching üben oder auf die man sich mit Literatur vorbereiten kann. Gruß, Nils

Moin, kannst du das bitte genau beantworten? Wo kommt auf welchem Wege in exakt welcher Situation welche genaue Meldung? Gruß, Nils

Moin, seit einigen Versionen kannst du den DC auch im GUI löschen: Einmal im AD-Benutzer und -Computer und dann im AD-Standorte und -Dienste. Das manuelle Metadata Cleanup ist dann typischerweise nicht mehr nötig. Danach solltest du aber auch noch im DNS (und ggf. im WINS) aufräumen: Entferne alle Einträge, die zu dem verwaisten DC gehören. Nicht nur die mit seinem Namen, sondern auch die mit seiner IP-Adresse (falls die jetzt nicht mehr zu einem DC gehört). Gruß, Nils

Moin, das sind getrennte Einträge. Dienst A hat die Adresse A und Dienst B hat die Adresse B. Die können natürlich unterschiedlich sein. Und sie können auch in verschiedenen IP-Netzwerken liegen. Die Frage wäre, was für ein A-Eintrag denn das für "die eigentliche Domain" sein soll - da es um öffentliche IP-Adressen geht, ist vermutlich der Webserver gemeint? Gruß, Nils

Moin, zu deinen Szenarien: Szenario 1 wäre nur dann so, wenn du die Portweiterleitung nicht richtig baust. Machst du es richtig, dann lässt du eben nur SSL-Verbindungen zum Exchange-Server durch. Für alles Weitere ist Exchange zuständig. Je nachdem, was die Firewall kann, lässt sich dort vielleicht noch Weiteres einschränken. Auf andere Server käme ein Angreifer so nicht - es sei denn, er findet eine Lücke in Exchange, die ihm das ermöglicht. Bislang sind solche Lücken aber nicht bekannt geworden. Die SSL-Schwäche, die du ansprichst, hat mit solchen Szenarien nahezu gar nichts zu tun und trifft auf Windows auch nicht zu, weil dort ja kein OpenSSL läuft. Szenario 2 kann genau solche Vorteile bieten, wie du grob beschreibst und wird u.a. deshalb meist vorgezogen. Gruß, Nils

Moin, Fragen wir mal in der richtigen Reihenfolge: was willst du denn erreichen? Gruß, Nils

Moin, Das "Kaputtspielen" im Lab wird überbewertet. Die Probleme der Praxis erfasst man damit in der Regel nicht. Gruß, Nils

Moin, und was für eine Fehlermeldung erhältst du genau in welcher Situation? Ist das ein Popup oder eine Meldung im Eventlog? Gruß, Nils

Moin, mit "kurze Namen" waren die NetBIOS-Namen gemeint, die im Unterschied zu DNS-Namen eben nur 15 Zeichen haben und keine Suffixe unterstützen. Vielleicht ist euer Szenario eines der wenigen, in denen eine "globalnames"-Zone im DNS eine Lösung wäre. https://technet.microsoft.com/de-de/library/cc731744(v=ws.11).aspx Gruß, Nils

Moin, meine Frage wäre eher: Warum würde man das tun wollen? Mir ist noch kein einziges Praxisszenario über den Weg gelaufen, in dem der Live-Export wirklich sinnvoll sein könnte. Gruß, Nils

Moin, warum schaltet ihr WINS ab, wenn ihr kurze Namen auflösen müsst? Das ist doch zu kurz gedacht. Nur um es noch mal zu betonen: WINS erhöht nicht die Broadcast-Last, sondern es reduziert sie. Namensauflösungsbroadcasts gibt es in Umgebungen ohne WINS. Also entweder auf ein anderes System zum Dateiaustausch umsteigen (bessere Lösung) oder WINS wieder einrichten (schlechtere Lösung). Das ist zwar eine Komponente, die man eigentlich nicht haben will, aber wenn man nicht auf sie verzichten kann, sollte man halt auch nicht darauf verzichten. (Und nein, der WINS-Angriff aus dem Sommer steht dem nicht grundsätzlich entgegen.) Gruß, Nils

Moin, man kann, aber du willst doch ein vorhandenes SAN dafür nehmen, oder? Gruß, Nils

Moin, und selbst wenn es das könnte, wäre Norberts Frage ja noch zu klären, was denn das werden soll. Also @calimero92, bitte beschreib mal, was du eigentlich vorhast. EDIT: OK, hat sich überschnitten. In dem Fall musst du einen Cluster einrichten. Die Details dazu finden sich in der Literatur, grundsätzliches Vorgehen: Alle drei Hosts grundinstallieren Auf allen Hosts Hyper-V installieren und grundkonfigurieren LUNs an den ersten Host anbinden auf dem ersten Host den Failover-Cluster einrichten und die LUNs als Cluster-Storage einbinden LUNs den anderen Hosts präsentieren, dort aber nicht online nehmen Die anderen Hosts dem Cluster hinzufügen Die Cluster-LUNs in CSVs konvertieren Gruß, Nils

Moin, Norberts Empfehlungen sind sinnvoll: erfahrene Berater einschalten und nicht einfach mal so drauflosmigrieren. Allgemeiner Input: [Welches Domänenmodell ist das Beste für Active Directory? | faq-o-matic.net] https://www.faq-o-matic.net/2007/06/09/welches-domaenenmodell-ist-das-beste-fuer-active-directory/ Gruß, Nils

Moin, die 1709 wird von Microsoft nicht als vollwertiger Server positioniert, sondern im Wesentlichen nur für Container. Das haben sie aber erst später gesagt. https://blogs.technet.microsoft.com/windowsserver/2017/10/26/faq-on-windows-server-version-1709-and-semi-annual-channel/ Gruß, Nils

Moin, keine Aufteilung in mehrere RAIDs. Darüber hinaus gäbe es zum Storage natürlich viel zu sagen, aber du wolltest ja nur diese Frage beantwortet haben. Gruß, Nils

Moin, ich auch, daher die Empfehlung ... [Zeitsynchronisation in virtuellen Umgebungen | faq-o-matic.net] https://www.faq-o-matic.net/2012/05/16/zeitsynchronisation-in-virtuellen-umgebungen/ [Virtuelle DCs: Zeitprobleme vermeiden | faq-o-matic.net] https://www.faq-o-matic.net/2010/04/21/virtuelle-dcs-zeitprobleme-vermeiden/ Gruß, Nils

Moin, Ja, das ist meine Empfehlung, allerdings für alle Mitglieder der Domäne, nicht nur die DCs. Gruß, Nils

Moin, der Plan ginge aber auch mit dem Erweiterten Sitzungsmodus nicht auf. Dabei werden die Ressourcen in die Benutzersitzung innerhalb der VM-Verbindung gemappt. Bei einem Recovery hättest du aber gar keine Benutzersitzung. Gruß, Nils

Moin, Du musst den Sitzungsmodus auch im den Einstellungen der VM einschalten. Gruß, Nils

Moin, ist denn das OS in der VM so konfiguriert, dass es einen Dump schreibt? Vielleicht kannst du die VM auch temporär aus dem Cluster nehmen, damit der sie nicht neu startet, sowas hilft manchmal, den Bluescreen nachzuverfolgen. Dass das Problem auf dem Host liegt, halte ich bei der Beschreibung eher für unwahrscheinlich. Sind die Integration Services aktuell? Gibt es noch irgendwelche sonstigen Treiber in der VM, vielleicht von einer P2V-Migration? Gruß, Nils

Moin, nein. Gruß, Nils

Moin, diese Frage könntest du auch noch mal beantworten. Bislang hast du dazu nichts gesagt. Gruß, Nils

Moin, du nutzt aber nicht dein Sysvol zur Software- und Datenverteilung, oder? Falls doch: Weg damit. Ins Sysvol gehören AD-Daten, sonst nichts. Gruß, Nils

Moin, es ist eher unwahrscheinlich, dass wirklich die Thin Clients damit zu tun haben. Die Sitzung und damit die Applikation laufen ja auf dem Server. Allenfalls könnte ich mir vorstellen, dass es kurze Verbindungsunterbrechungen gibt, mit denen die Session auf dem Server dann irgendwie nicht klarkommt. Aber auch das wäre jetzt nur ins Blaue, ohne dass ich jemals konkret davon gehört hätte. Hardwarefehler lassen sich ausschließen, z.B. dass Tastatur oder Maus auf den Clients nicht richtig funktionieren und irgendwas "Falsches" an die Applikation senden? Gruß, Nils