NilsK

Moin, BranchCache ist, wie Norbert schon sagt, nicht das, wofür viele es halten. Aus meiner Sicht ist es entwickelt worden, ohne einen existierenden Bedarf zu decken. Es handelt sich um einen reinen Lese-Cache. Jedes Speichern findet auf dem Dateiserver selbst statt, nicht auf dem Cache. Noch dazu mit "erhöhten Kosten", weil erst geprüft werden muss, ob die Version im Cache denn überhaupt noch aktuell ist. Damit eignet es sich faktisch nur für Read-only-Daten. Ich habe noch keinen Kunden gesprochen, für den sowas von Interesse wäre. Gruß, Nils

Moin, wenn der räumliche Radius etwas größer sein darf (Hannover): https://www.netz-weise-it.training/seminaruebersicht/powershell.html Das sind keine MOCs, sondern praxisorientierte Seminare. Ich habe mit dem Anbieter gute Erfahrungen gemacht (ist hier nebenan, aber weder verwandt noch verschwägert ;)). Gruß, Nils

Moin, wie die Kollegen schon sagen, musst du die Serverlizenzen nicht technisch zuweisen. Du musst sie "nur" im Fall eines Audits nachweisen können, es handelt sich um eine logische Zuweisung. Denk zur Analogie an vSphere: Auch dort brauchst du dieselben Windows-Lizenzen, wirst aber nirgends einen Key eingeben. Im Fall von Hyper-V trägst du einen (beliebigen) der Keys im Management-OS ein und aktivierst diesen. Technisch war das dann alles. Bei den VMs läuft es genauso: Dort trägst du einen Key ein und aktivierst das Gast-OS. Da die Replikate ja Replikate sind, musst du da nichts extra machen. Gruß, Nils

Moin, vor allem musst du vom Recovery her denken. "Backup" ist viel zu kurz gesprungen. Was musst du in welcher Situation in welcher Qualität und welcher Zeit wiederherstellen können? Das ist bei keinem Unternehmen aus dem Bauch zu beantworten, sondern erfordert Analyse, Planung und Gespräche mit den Fachabteilungen. Gruß, Nils

Moin, a.) nein b.) dies hier dürfte dem Grundsatz nach noch immer zutreffen: [Hyper-V Replica: Wie lizenziert man das? | faq-o-matic.net] http://www.faq-o-matic.net/2014/05/12/hyper-v-replica-wie-lizenziert-man-das/ Gruß, Nils

Moin, meinem Verständnis nach funktionieren Open- bzw. Volume-Lizenzen für Desktop-Windows nur als Upgrade-Lizenzen. Mit einer solchen Lizenz wird eine bereits vorhandene, gültige Lizenz nachträglich zu einer Volumenlizenz. Heißt: Ein Unternehmen kauft PCs mit einer OEM-Lizenz für Windows und kann für diese dann Open-Lizenzen nachkaufen, um daraus Volumelizenzen zu machen. Soweit richtig? Nun haben viele Kunden (und leider auch viele Händler) das seit vielen Jahren falsch verstanden und PCs ohne Windows-Lizenz gekauft, um diese dann nur mit einer Open-Lizenz auszustatten. Meinem Verständnis nach wären diese PCs nicht richtig lizenziert. Richtig? Was könnte ein Kunde nun aber tun, um die fehlenden Lizenzen zu "heilen"? Also so, dass Microsoft das bei einer Überprüfung (mit ausreichender Wahrscheinlichkeit) akzeptieren würde? Gebrauchte OEM-, Systembuilder- oder FPP-Lizenzen kaufen? Neue Systembuilder- oder FPP-Lizenzen kaufen? Ganz was anderes? Danke & Gruß, Nils

Moin, nein, Terminalserver reduzieren nicht den Lizenzbedarf. Haben sie noch nie. Für 540 User brauchst du 540 User-Cals - oder eben 540 Device-CALs, die dann den Endgeräten zugeordnet sind (auch wenn dies keine Windows-Maschinen sind). Gruß, Nils

Moin, wie liest du da raus, dass jemand was gegen Veeam gesagt habe? Da steht, du brauchst ein schlüssiges Backup- und Restorekonzept. Und das "sinnvoller" bezieht sich nicht auf Veeam, sondern auf die Frage, ob es denn ein Synology mit HA sein soll, soweit ich es verstehe. Gruß, Nils

Moin, gar nichts, hat doch auch niemand gesagt, oder? Gruß, Nils

Moin, klare Antworten hängen ganz entscheidend von der Frage ab ... ... und da kann man bei deiner Frage leider nicht viel mehr sagen als: Kommt drauf an. Ohne die Anforderungen und den Leistungsbedarf der Applikationen zu kennen, kann man schlechterdings nicht sagen, ob die Leistung der Synologies ausreichen würde. Kann sein, kann nicht sein. Allgemein gibt es in der "professionellen" IT-Szene Vorbehalte gegen Synology und andere Hersteller, die aus dem SOHO-Bereich kommen. Ich weiß, dass Synology, QNap und andere durchaus nachgelegt haben und leistungsstärkere und zuverlässigere Systeme im Portfolio haben als früher, aber für meinen Bereich rate ich auch weiter "eher" davon ab. Wenn du dein Budget schonen willst, solltest du prüfen, ob es wirklich vSphere sein muss oder ob Hyper-V nicht ausreicht. Sieben 2012-R2-Lizenzen bedeuten, dass du insgesamt 6 VMs in der Farm betreiben kannst, weil du jedem Host drei Lizenzen zuweisen kannst. Wozu ist dann die siebte Lizenz da? Gruß, Nils

Moin, "keim"? Du meinst "kaum"? In dem Fall: Naja, kommt ganz auf den Abstraktionsgrad an. Im Wesentlichen schon, im Detail nicht. ;) Wenn dein Exchange ein Einzelserver werden soll, brauchst du keinen Load Balancer. (TMG war aber keiner.) Für SMTP-Mailempfang brauchst du kein kommerzielles Zertifikat. (Wobei die heute aber auch nicht mehr teuer sind - sobald OWA und ActiveSync ins Spiel kommt, verzichtet man nicht mehr darauf.) Eine Firewall, die auch Remote Proxy kann (oder ein separater Remote Proxy) ist für OWA sinnvoll. Gruß, Nils

Moin, bitte - brich ab. Es ist nicht so wichtig, als dass du das Risiko erzeugen solltest. Gruß, Nils

Moin, ich schließe mich Norbert an. Brich ab und lass es, wie es ist. Die verwaisten SID-Einträge stören ja nicht. Wenn du dann mal jemanden im Haus hast, der sich auf der Ebene auskennt, besprich das Vorgehen mit ihm. Einstweilen kann das so bleiben. Das Risiko, dass du jetzt aufgrund von Missverständnissen was kaputt machst, ist zu groß. Gruß, Nils

Moin, ja. Also entferne sie dort. Gruß, Nils

Moin, nein, von wo sind die Einträge geerbt? (Nicht: wohin werden sie vererbt) Vermutlich von der Domänen-Ebene. Dann kann man die da einmalig entfernen und sie verschwinden auch aus der Vererbung. Das macht man an der Stelle manuell. Gru´ß, Nils

Moin, könntest du deine Beiträge bitte mit Groß- und Kleinschreibung verfassen? Es ist sonst unnötig schwer, das zu lesen. Danke. Dein Exchange ist also auf demselben Server installiert wie das AD? Das ist "not recommended". Dein Exchange ist direkt ans Internet angebunden? Ohne Firewall? Oder wie? Man kann Exchange über eine Firewall ans Internet anbinden, aber zu empfehlen ist das nicht. Übliche Konfigurationen arbeiten hier mit einem Reverse Proxy, der nur die benötigten (https-) Zugriffe zulässt. LDAP ist natürlich nicht nach außen geführt, wozu auch? Antwortet denn auf der externen Adresse der DC auf Port 389? Bevor du dich mit Schwergewichten wie den BSI-Empfehlungen befasst, solltest du anscheinend noch ein wenig Design-Know-how aufbauen - ohne dir zu nahe treten zu wollen. Gruß, Nils

Moin, da steht nicht, dass du einen Alias einrichten sollst. Gemeint ist, dass der Server selbst in seiner IP-Konfiguration den Verweis auf einen passenden DNS-Server hat. Gruß, Nils

Moin, du willst uns jetzt aber nicht sagen, dass dein AD aus dem Internet direkt erreichbar ist, oder? Um hier Empfehlungen aussprechen zu können, müsste man den Aufbau der Umgebung und die Anforderungen kennen. Generische Hinweise wie die des BSI kann man nicht einfach so umsetzen. Gruß, Nils PS. Abgesehen davon, sind die BSI-Hinweise hier auch nicht hilfreich. Durch LDAPs beispielsweise verhindert man nicht den unerwünschten Zugriff auf LDAP, sondern man sorgt für verschlüsselte Daten. So erhielte ein ANgreifer auch dieselben Informationen, nur eben in einer verschlüsselten Sitzung, es könnte also niemand anderes die Informationen belauschen, die da an ungebetene Gäste hinausgehen ...

Moin, du meinst als Berechtigungseinträge in Dateien? Am besten mit SetACL: https://helgeklein.com/blog/2012/07/finding-removing-orphaned-sids-in-file-permissions-or-busting-the-ghosts-built-into-windows-7/ Gruß, Nils

Moin, ja, das ist nachvollziehbar. Das Dateisystem selbst behält die Berechtigungen beim Verschieben auf demselben Volume bei, weil sich die Metadaten des Objekts nicht ändern. Der Client kann dies beeinflussen, wenn der User die Rechte dazu hat (Berechtigungen ändern) - aber nur, wenn er eine Funktion dafür hat (mit Bordmitteln nur der Explorer, soweit ich weiß) und wenn das auch klappt (bei Windows 7 klappt das nicht immer, es gab mal einen Hotfix, der in aktuellen Installationen aber wohl nicht mehr funktioniert). Gruß, Nils

Moin, den dcdiag-Fehler kannst du ignorieren oder beheben, indem du forestprep /rodcprep ausführst. Die DNS-Konfig ist korrekt? [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] http://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Ansonsten sollte folgende Befehlsfolge vom DC aus die nötige Struktur wiederherstellen: net stop netlogon net start netlogon ipconfig /registerdns Gruß, Nils

Moin, das kann man so nicht beantworten, weil es von den konkreten Anforderungen abhängt. Mögliche Elemente zur Umsetzung umfassen organisatorische Vorgaben, wie du sie nennst, Reparaturskripte, eingeschränkte Berechtigungen, gezieltes Aufteilen von Datenspeichern, Umstieg auf andere Techniken (Sharepoint, DMS ...) ... Gruß, Nils

Moin, das Problem dabei ist, dass die Client-Implementierung sich hier nach Windows XP geändert hat, möglicherweise sogar mehrfach. Daher ist es schwer vorherzusagen, was nun wirklich passiert und wie man das in den Griff bekommt. Ich bin mit einem Kunden gerade in einem Projekt, wo das eine Rolle spielt. Eine richtig schöne Lösung scheint es dafür nicht zu geben. Gruß, Nils

Moin, wenn du es mit Gruppen machen willst, dann kehre die Logik um: Gruppe 1 enthält alle Benutzer mit speziellen Funktionen, Gruppe 2 alle ohne diese Funktionen. Gruppe 3 enthält Gruppe 1 und Gruppe 2. Wenn du die User für Gruppe 2 nur per Ausschluss identifizieren kannst, bleibt eben nur eine Skriptlösung. Gruß, Nils

Moin, was du aus deinem Konzept hinbekommst, sind die beiden Exchange-Server, die jeweils nur einen Teil der Mailboxen für die lokalen User halten. Eine durchaus übliche Lösung. Schon bei dem "zentralen Smarthost" wird es aber kritisch. Wo soll der stehen, damit er auch bei Ausfall der WAN-Verbindung noch Mails an die Exchange-Server senden kann? Anhand von was soll er entscheiden, wohin welche Mail geht? Und was gar nicht gehen wird, ist deine Idee zur "Spiegelung" der Mail-Datenbanken an den jeweils anderen Standort. Wenn die Leitung das hergeben würde, könnte man mit demselben Aufwand auch eine "echte" DAG bauen. 4 Mbit werden für sowas aber nicht ausreichen, zumal die Leitung ja sicher auch noch für was anderes gebraucht wird. In solchen Situationen ist es regelmäßig sinnvoller, die User zu den Daten zu holen - also ein zentrales Exchange-System, das man dann vielleicht auch ohne riesige Klimmzüge höher verfügbar machen kann. Die User des anderen Standorts greifen dann darauf zu. Sollte die WAN-Verbindung gestört sein, ist kein aktiver Verkehr möglich, durch Cache-Mode aber immerhin Arbeit mit den vorhandenen Daten. Und parallel schaut man zu, dass man die Verfügbarkeit der Anbindung verbessert. Ständig ausfallende Leitungen muss man heute nicht mehr hinnehmen. Also im Wesentlichen das, was Beitrag #2 schon sagt ... Gruß, Nils