cj_berlin

Also alles Rechtliche steht in den License Terms bzw. PURs. https://www.microsoftvolumelicensing.com/userights/documenthome.aspx

Moin, ist es denn gesichert, dass das Netz das Bottleneck ist? Nach Deinen Daten (1,6 TB in 14 Stunden = 13.107 GBits in 50.400 Sekunden) kommt man auf 0,26 GBps, damit wird selbst bei einer 1GBps-Karte nur ein Viertel der Bandbreite ausgenutzt...

Nein, warum denn? Es gibt doch nur eine Exchange-Instanz... Bitte doch den Consultant, Dir die Stelle in den PURs zu zeigen, aus der das hervorgeht

Moin, das C in CAL steht für Client, das hat nur mit der Version der Server etwas zu tun, auf die zugegriffen wird, nicht mit deren Anzahl. Server-Lizenzen ja, da man das Blech lizenziert, muss man in einem Cluster alle Knoten lizenzieren (vereinfacht gesagt).

Davon abgesehen, kann das Speichern von Cleartext Credentials in Textdateien niemals eine Lösung sein.

Hah - ich habe sogar einen Kunden, der schriftlich definiert hat: "Offline-Arbeiten gibt es nicht". In aller Konsequenz gibt es dann AlwaysOn-VPN und keine Cached Credentials auf Notebooks, die 90% der Zeit draußen sind. Aber so etwas ist in der Tat eher die Ausnahme. Ich bin da inzwischen bei der Ansicht angekommen, dass Modern Management ohne Domain-Mitgliedschaft der Clients plus Terminalserver/VDI zum produktiven Arbeiten das langfristig bessere Konzept ist als der "closely managed" Client...

Ich meine, in dem Moment, wo sie gecached werden, bei der ersten Anmeldung nach dem letzten Passwortwechsel.

Kommt auf die konkrete Fragestellung an. Auch Cached Credentials wurden ursprünglich gegen das AD bestätigt, wenn es ein AD-Account ist. Insofern, die Frage "wo hat sich User X jemals interaktiv angemeldet?" kann mit den Logs von den DCs sehr wohl zufriedenstellend beantwortet werden. Die Frage "wo hat sich User X gestern interaktiv angemeldet?" kann natürlich nicht genau damit beantwortet werden, sofern Cached Credentials aktiv sind. Sie sind aber hoffentlich nicht aktiv auf: Servern, PAWs und idealerweise auf allen Geräten, die per LAN angeschlossen sind.

Martin, ich bin voll bei Dir, aber jetzt unternimmt Microsoft ja schon den zweiten Versuch, das Startmenü abzuschaffen. Und im Gegensatz zum Windows 8-Startscreen, den man wenigstens in Ordner strukturieren konnte, ist der neue Kram ja gänzlich für die Füße... Desktop ist eigentlich ein Konzept, das man sehr gut produktiv nutzen kann, wenn man a. mehr mit Dokumenten arbeitet als mit Programmen, und b. mehr allein arbeitet als zusammen. Deshalb ist der Schreibtisch beim Mac ja immer noch so zentral und wird dort auch nicht in Frage gestellt...

...das Ergebnis bei der nächsten Anmeldung ist das gleiche (Zustand wie vor der ersten Anmeldung) und User Experience ist konsistenter (das, was nicht verändert wird, kann auch nicht verändert werden). Aber hey, ich kenne sogar Kunden, die den Desktop umleiten und die Umleitungsziele jede Nacht per Skript löschen, damit die User es sich abgewöhnen, Sachen auf dem Desktop zu speichern. Vielleicht beschreibst Du mal, was Du *wirklich* erreichen willst?

Moin, die Standard-Antwort hierauf ist "Mandatory Profiles": https://docs.microsoft.com/en-us/windows/client-management/mandatory-user-profile Das ist aber nicht Jedermanns Sache

Moin, damit ein Domänen-Rechner einer PKI vertraut, muss das Root-Zertifikat dieser PKI in seinem "Trusted Roots"-Store landen. Dafür gibt es vier Möglichkeiten: Registry = Du importierst einzeln Third Party = Microsoft importiert Group Policy = Group Policy Enterprise = DU veröffentlichst im LDAP Wenn also den Zertifikaten einer PKI in einem Forest vertraut werden soll, kannst Du zwischen den beiden unteren Varianten auswählen. Um Zertifikate zu beantragen, kannst Du natürlich Webservices einsetzen. Aber das Vertrauen muss trotzdem irgendwie hergestellt werden. In welche Richtung gehen denn die Trusts?

Moin, wenn Du in den Views die Spalte einfach nur mit ausgibst, ändert sich nichts (außer dem ausgegebenen Datentyp). Dort, wo Du die Spalte auswertest und/oder transformierst, muss die Bedingung/die Transformation datetime berücksichtigen statt nvarchar.

Moin, mit "Host" meinst Du vermutlich gerade nicht "Host" (das wäre ein ESXi, kein Windows Server), sondern "VM", richtig? Es spricht nichts gegen diese Vorgehensweise, wenn Du ein großes Volume brauchst.

Moin, Security Logs aller DCs nach Event 4624 durchsuchen und die Metadaten der Events auswerten. Damit das funktioniert, Auditing einschalten. Alternativ: Auf allen Clients die C:\Users\*\NTUSER.DAT auflisten und den Zeitstempel auswerten.

Hier noch der obligatorische Hinweis, dass DHCP **und** WDS sind beides keine guten Kandidaten um auf DCs ausgeführt zu werden.

In dieser Hinsicht schon. Als es den Symantec Mail Security Gateway noch gab, war die Standard-Einstellung im zweibeinigen Setup genau so: es gibt eine Liste interner SMTP-Domains es gibt ein externes und ein internes Bein Mails mit Absendern (From: Header und/oder MAIL FROM:) aus internen Domains auf dem externen Bein werden sofort verworfen Mails ohne From: Header werden sofort verworfen Natürlich hat es den Leuten nicht gefallen, funktioniert hat es aber. So ziemlich das einzig gute, was ich über dieses Produkt sagen kann.

Das hilft aber nicht, wenn die Mail über den internen Connector reinkommt, aber nicht von dem angegebenen Absender stammt... Aber besser das als nichts. Vernünftige Mail-Gateways werden in der Regel eine vermeintlich interne Mail auf dem externen Bein gar nicht erst reinlassen.

Du meinst sicherlich, ihr habt eine interne PKI und nutzt die von dieser signierten Zertifikate? Selbstsigniert ist etwas anderes. In Outlook gibt es diese Möglichkeit nicht. Du könntest ein Makro schreiben, das beim Absenden feuert, schaut, an wen die Mail geht und dann signiert, falls intern. Was machst Du, falls eine Mail sowohl interne als auch externe Empfänger hat? Und habt ihr keine anderen Clients außer Outlook? OWA? Mobiltelefone? Mit denen wird alles, was Du für Outlook zusammengebastelt bekommst, nicht funktionieren... Was wäre so schlimm daran, Mails generell zu signieren, außer dass manche Leute anfangen könnten, euch verschlüsselte Mails zu senden? Man müsste einen CDP öffentlich verfügbar machen, aber es ist ja nur ein Webserver, auf dem zwei bis drei Dateien liegen...

Ja, sicher. Ist auch des Öfteren passiert, auch mit nennenswerter Belastung (VMs, Migrationstools usw.)

Moin, Du machst Dir das Leben viel zu schwer Wie wäre es mit der folgenden Modifikation: Die VM hat alle FSMO-Rollen inne An dem Tag, wo Du ein Backup der VM über den Air Gap schickst, zwingst Du alle Member (die online sind, also zumindest alle Server) ihr Computer-Kennwort zu ändern Wenn der Ernstfall kommt, machst Du folgendes: Physische DCs platt machen VM wiederherstellen Physische DCs aus den Metadaten bereinigen Physische DCs mit den alten Namen und IP-Adressen wieder promoten glücklich sein und Dich anspruchsvolleren Aufgaben zuwenden, die in solch einem Fall anfallen Das ganze beruht natürlich darauf, dass Du von den Membern irgendwie ein sauberes Bare Metal-Backup hast, denn diese werden vermutlich noch vor den DCs verschlüsselt, und selbst wenn nicht, Persistence kannst Du auf Membern doch auch nicht ausschließen, wenn die Umgebung schon befallen ist...

Danke! Und falls jemand von den "Enterbten" das doch noch einmal versuchen möchte - sagt bescheid

Moin, ohne Hybrid wird es schwierig. Also, um genau zu sein, ist es ohne Hybrid gar nicht vorgesehen.

So halte ich es auch. Mein Schwiegervater ist auch nach Jahren noch pissed, aber da muss er durch

...und Du hast natürlich ESU für Deinen Server 2008 abgeschlossen, damit er weiter gepatcht und vor Bedrohungen geschützt wird?