NilsK

Moin,
 
nein, reg-Dateien unterstützen keine Variablen. Bliebe also, wenn das Verfahren festgelegt ist, nur ein Workaround, der für jeden Variableninhalt vor dem Import eine eigene reg-Datei erzeugt.
 
Gruß, Nils

Moin,
 
kurze Antwort: Der Gedanke ist naheliegend, aber vergiss es.
 
Längere Antwort: Weder das AD noch Exchange sind wirklich für so ein Mandantenmodell geeignet. Man müsste derart viel in den Berechtigungen des AD und von Exchange ändern, dass die Umgebung kaum noch verwaltbar ist. Zudem befindet man sich sehr schnell in einem Zustand, der von Microsoft nicht mehr supported wird.
Du müsstest ein AD bauen, in dem User eines Kunden die User anderer Kunden nicht "sehen" können. Das erfordert sehr komplexe Berechtigungen, die teilweise für jedes Objekt neu gesetzt werden müssten. Da Exchange sich seit einigen Jahren nicht mehr an die AD-Berechtigungen hält, müsstest du das für Exchange dann noch mal separat machen. Mit sehr viel Aufwand bekommt man das zwar technisch hin, es ist dann aber sehr wahrscheinlich, dass viele Programme und Funktionen nicht richtig damit klarkommen.
 
Die meisten Hoster haben das auch festgestellt und arbeiten daher tatsächlich mit einer Umgebung pro Kunde. Bezüglich der Lizenzkosten macht das meines Wissens kaum einen Unterschied: Da man hier mit SPLA-Lizenzierung arbeiten muss, ist die Zahl der User das Kriterium, die Serverlizenzen fallen dann kaum noch ins Gewicht.
 
Ich habe das mit mehreren Kunden durchevauliert, die haben sich alle für das simple Modell "eine Domain pro Kunde" entschieden. Für die Administration könnte man sich dann überlegen, eine zentrale Admin-Domain zu bauen, die die Adminkonten hält und per Trust auf die Kundendomains zugreift. Das hat aber Sicherheitsimplikationen, die man auch sorgfältig durchdenken sollte.
 
Gruß, Nils

Moin,
 
wenn es grafisch sein soll und dein Unternehmen bereit ist, eine geringe Summe für nützliche Tools auszugeben, empfehle ich ISESteroids von Tobias Weltner. Das ist eine Erweiterung, mit der aus der PowerShell ISE eine vollwertige Entwicklungsumgebung wird. Nicht nur, aber eben auch für "echte" grafische PowerShell-Oberflächen.
 
Gruß, Nils

Moin,
 
nimm es uns nicht übel - aber genau das ist die Sorte Grundlagen, die ein Forum nicht vermitteln kann. Auch wenn es hier gewissermaßen um "fortgeschrittene Grundlagen" geht.
 
Wie du ein Backup wiederherstellen musst, hängt von der ganz konkreten Situation ab. Was willst du wiederherstellen, in welchem Zustand ist der Server, wie hast du gesichert ...
SQL Server bzw. das Management Studio können dir vorschlagen, was du wiederherstellen könntest, wenn sie Zugriff auf de Sicherungsverlauf haben. Im Fall eines Server-Recoverys haben sie das nicht, da musst du dann also selbst wissen, was du tun musst. Wenn du gar nicht alles wiederherstellen musst, sondern einen bestimmten historischen Stand brauchst, dann nützt dir der Vorschlag des SSMS auch nichts.
 
Es empfiehlt sich - wie eigentlich immer bei der Recovery-Planung - die nötigen Schritte vorzuplanen und zu üben. Dabei kann man dann auch wertvolle Hinweise erhalten, mit denen man z.B. ein Skript aufbauen kann, das Dinge vereinfacht und Fehler vermeidet.
 
Gruß, Nils

Moin,
 
ja:
 
 
Relevant ist hier Punkt 4. Quelle: aktuelle Product Terms auf Deutsch.
 
[Products and Online Services | Microsoft Volume Licensing]
https://www.microsoft.com/en-us/Licensing/product-licensing/products.aspx
 
Gruß, Nils

Moin,
 
dann könntest du mit einem Hilfsmittel wie z.B. LIZA mal vergleichen, wie die Berechtigungen neu erzeugter Objekte denn tatsächlich sind. Wer weiß, ob die "umsortierten" Strings nicht vielleich ungültig sind und das AD dann was anderes macht, als nominell dort steht ...
 
http://ldapexplorer.com/en/liza.htm
 
Gruß, Nils

Moin,
 
man kann CAD grundsätzlich auch per Remotedesktop machen, es wird dann allerdings teuer ...
 
Jede Art von Datenverteilung, auch mit einem Distributed Locking, würde aber kaum noch sinnvoll funktionieren, sobald die Daten wirklich gemeinsam verwendet werden sollen. Irgendwann kommt der Zeitpunkt, wo die Daten über die Leitung müssen. Auch DFS-R würde daran ja nichts ändern. Mit Distributed Locking habe ich mich bislang nicht näher befassen müssen, weil es in Kundensituationen dann immer andere Lösungen bzw. Ansätze gab - nicht zuletzt, weil sich einige Dinge eben nicht wegdiskutieren lassen wie eben der notwendige Traffic.
 
Da ich die Situation bei euch nicht beurteilen kann, habe ich nur die Empfehlung, das noch mal in Ruhe zu durchdenken. Von organisatorischen Lösungen über WAN-Optimierung bis zum Erhöhen der Bandbreite ist ja ein ganzes Spektrum denkbarer Ansätze vorhanden.
 
Was die Vertrauensstellung betrifft: Grundsätzlich heißt Vertrauen eben "Vertrauen" - die vertrauende Domäne lässt alle Anmeldungen der vertrauten Domäne zu. Sicher kann man die Zugriffe dann beschränken, aber man muss es dann eben auch tun. Daher sollte man sowas vorher in Ruhe durchdenken. Technisch ist das in 30 Minuten eingerichtet, aber es hat organisatorische Folgen.
 
Gruß, Nils

Moin,
 
es geht hier um gleichzeitige Vorgänge. Das ist absichtlich begrenzt, weil LAN, Storage, Server usw. dem gleichzeitigen Datentransfer Grenzen setzen können. Ohne die tatsächlichen Gegebenheiten zu kennen (und ggf. zu testen), würde ich das nicht einfach hochsetzen, das kann auch nach hinten losgehen.
 
Du findest im Web Leute, die das mal eben auf 50 hochsetzen und behaupten, alles sei toll, aber das gilt ganz sicher nicht für jede Umgebung.
 
Gruß, Nils

Moin,
 
geht aus dem Artikel bzw. den damit zusammenhängenden Artikeln hervor. Du hast einige Konfigurations- und Variationsmöglichkeiten, aber das Whitelist-Prinzip kannst du nicht grundsätzlich umkehren. Das würde ja den Ansatz aushebeln.
 
Blacklist-Methoden kannst du auf anderen, technisch "älteren" Wegen umsetzen, aber das führt i.d.R. nicht sehr weit, weswegen Microsoft eben die SRP bzw. AppLocker entwickelt hat.
 
Gruß, Nils

Moin,
 
das Limit für Gruppenmitgliedschaften prop User liegt bei gut 1000 Stück. Daher würde ich bei eurer Unternehmensgröße noch kein Problem technischer Natur erwarten. Auch auf die Performance wird sich dies nicht spürbar auswirken, da gibt es beim Dateizugriff andere Faktoren, die ins Gewicht fallen.
 
Gleichwohl ist der Grundgedanke zutreffend. Es ergibt gerade bei solchen Konstrukten Sinn, möglichst viel an Strukturen und Berechtigungen logisch zusammenzufassen und möglichst wenige Ausnahmen zu definieren, die separate Gruppen erfordern. Als Grundansatz für die Umsetzung im AD empfehle ich das A-G-DL-P-Prinzip.
 
[Windows-Gruppen richtig nutzen | faq-o-matic.net]
https://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/
 
Gruß, Nils

Moin,
 
Office 365 kann man auch als Privatperson beziehen. Das gilt auch für die Business-Pläne. Und schon mit dem "kleinsten" Plan kann man auch die Domain einbinden. Die sollte dann bei einem Provider laufen, wo man als Kunde entweder direkt DNS-Einträge bearbeiten kann oder wo der Providersupport das macht und Erfahrung damit hat.
 
Du könntest dann an dein Abo zwei Lizenzen anbinden, und dann kannst du mit deiner Frau so kommunizieren, als hättet ihr einen Exchange Server. Nach außen natürlich sowieso.
 
Gruß, Nils

Moin,
 
im Wesentlichen liegst du richtig. Mögliche Performance-Auswirkungen entstehen durch das Logging selbst (welches man nicht abschalten kann), aber nicht durch das Recovery Model. Wenn es also kritisch auf Performance ankommt, braucht man für die Logs ein Storage, das lineare Schreibvorgänge schnell erledigt.
 
Gruß, Nils

Moin,
 
bei so kleinen Standorten würde ich überhaupt keine DCs einplanen.
 
Bei einem RODC muss man u.a.:
definieren, welche Userpasswörter synchronisiert werden definieren, welche Computer dort stehen, damit deren Passwörter synchronisiert werden die DNS-Updates steuern die lokale Administration definieren und steuern usw. Gruß, Nils

Moin,
 
zunächst sollte eine CA nicht auf einem DC installiert werden. Ich würde sogar sagen: Da gehört sie auf keinen Fall hin.
 
Dann: Vielleicht wäre es sinnvoll, die Umstellung zum Anlass zu nehmen, die PKI noch einmal konzeptionell zu überdenken. Für kleine Unternehmen kann eine einstufige PKI zwar ausreichen, aber das sollte man durchaus noch mal prüfen, ob das (noch) zutrifft.
 
Und schließlich: Abhängig davon, wie die PKI bislang genutzt wurde, könnte man sie auch einfach gar nicht migrieren und stattdessen eine neue aufbauen. Die vorhandenen Zertifikate ließe man dann einfach auslaufen - oft ist das ein gangbarer Weg. Für die Zeit muss man nur sicherstellen, dass das Root-Zertifikat und die CRL an mindestens einem Pfad verfügbar sind, der in den Zertifikaten angegeben ist. Dafür muss man die alte CA nicht online halten, es müssen nur die Pfade erreichbar sein, z.B. auf neuen/anderen Servern, die denselben Namen haben. Natürlich hängt das von einer Prüfung ab, ob dieser Weg möglich ist.
 
Falls migriert werden soll, dürften die für ältere Versionen dokumentierten Verfahren auch mit Windows Server 2016 noch funktionieren.
 
Gruß, Nils

Moin,
 
jupp, das ist UAC. Den Explorer kann man allerdings nicht als Admin starten, jedenfalls nicht ohne heftige Klimmzüge. Daher rate ich entweder zu einem anderen Dateimanager oder (besser) zu einem anderen Konzept: Admin-Berechtigungen nicht für die vordefinierten Admingruppen vergeben, sondern für selbst erzeugte. Dann funkt UAC nämlich nicht dazwischen.
 
[Windows-Berechtigungen mit UAC verwalten | faq-o-matic.net]
https://www.faq-o-matic.net/2015/12/23/windows-berechtigungen-mit-uac-verwalten/
 
Gruß, Nils

Moin,
 
Bei "Klonen" bin ich immer skeptisch. Lieber ein guter Nachbau. Auf faq-o-matic habe ich Anleitungen dafür.
 
Gruß, Nils

Moin,
 
es gilt die dringende Empfehlung, IPv6 aktiv zu belassen. Die Autokonfiguration sorgt dafür, dass es im eigenen Netzwerk (normalerweise) problemlos funktioniert.
Microsoft testet schon seit vielen Jahren nicht mehr ohne IPv6, daher kann es bei Abschalten zu seltsamen Problemen kommen, die Microsoft dann auch nur eingeschränkt unterstützt.
 
Ausnahmen sollte man nur machen, wenn es wirklich angezeigt und begründet ist.
 
Wichtig aber: Spätestens wenn der Provider IPv6 bereitstellt, muss ein Gesamtkonzept für IPv6 her. Da das aber (bei Firmen) nicht einfach so geschieht, kann man das i.d.R. dann in Ruhe planen. Bis dahin: Don't touch, don't switch off.
 
Gruß, Nils

Moin,
 
es gibt FSMO-Rollen. Aber es gibt keinen PDC.
 
Es gibt einen "PDC-Emulator" (bisweilen "PDCe" genannt), dessen namensgebende Funktion mit dem Tod von WIndows NT aber entfallen ist. Jetzt zentralisieren sich dort ein paar Nebenaufgaben. Aber diese Rolle hat nichts mit dem ehemaligen PDC-Konzept zu tun. Auch in die Handhabung des Kennworts ist der PDCe nur am Rande involviert. Die Durchführung liegt bei dem DC, der halt gerade angefragt wurde, also nicht zentral.
 
Gruß, Nils

Moin,
 
ja, kann man machen. Man kann allerdings auch einfach den Scope oder den Dienst deaktiviert lassen, solange er nicht arbeiten soll. Bei Migrationen machen wir üblicherweise beides - deaktivieren und de-autorisiert lassen. Nur aus Vorsicht, doppelter Boden und so - ein falsch antwortender DHCP ist echt ärgerlich.
 
Man kann einen DHCP auch per Textfile vorbereiten (netsh). Eine Freude ist das nicht, aber eben bei Migrationen usw. durchaus praktisch. Wir haben z.B. auch DHCP-Server mit aufwändiger Konfig im Lab vorbereitet und dann per netsh aufs produktive System übertragen.
 
Gruß, Nils

Moin,
 
da in den allermeisten Umgebungen die WSUS-Datenbank nur operativen Zwecken des WSUS-Systems selbst dient, ist etwas anderes als WID eine exotische Kombination. Sofern es also keine definierten Anforderungen gibt, die Datenbank mit höherer Priorität zu behandeln, würde ich beim Standard bleiben.
 
Gruß, Nils

Moin,
$Start = Get-Date $Duration = New-TimeSpan -Minutes 5 $End = $Start + $Duration Do{ Start-Sleep -Seconds 1 $DisplayTime = New-TimeSpan -Start $(Get-Date) -End $End $Time = "{0:D2}:{1:D2}" -f ($DisplayTime.Minutes), ($DisplayTime.Seconds) Write-Progress $Time } While((Get-date) -lt $End) Gruß, Nils

Moin,
 
 
genau dafür ist lastLogonTimestamp da. Du brauchst ja gar nicht das genaue Datum, sondern eben gerade nur ein ungefähres. Es interessiert dich ja nicht, ob der User heute um 10:20 oder um 8:46 sich angemeldet hat, sondern ob das schon mehr als x Tage her ist.
 
https://blogs.technet.microsoft.com/heyscriptingguy/2010/01/27/dandelions-vcr-clocks-and-last-logon-times-these-are-a-few-of-our-least-favorite-things/
 
Noch einfacher wäre übrigens OldCmp von Joe Richards: http://www.joeware.net/freetools/tools/oldcmp/index.htm
 
@testperson: 104 Tage sind nicht nötig, wenn man 90 Tage meint. Die 14 Tage muss man nicht draufschlagen - alles, was älter als 14 Tage ist, ist akkurat.
 
Gruß, Nils

Moin,
 
reicht es evtl. aus, das Dienstkonto in die lokale Gruppe "Ereignisprotokollleser" aufzunehmen?
 
Gruß, Nils

Moin,
 
nö, works as designed. Das Schreibschutz-Attribut verhindert, dass Inhalte der Datei geändert werden. Das dürfte auch funktionieren. Ein Löschen der Datei verhindert man damit nicht, hat man auch noch nie.
 
Du müsstest also mit Berechtigungen arbeiten.
 
Gruß, Nils

Moin,
 
erteile auf der übergeordneten Freigabe nur das Recht "Ändern", nicht "Vollzugriff". Dann können Benutzer die Berechtigungen auf keinen Fall ändern, auch wenn sie Besitzer sind.
 
[Datei- und Freigabeberechtigungen in Windows | faq-o-matic.net]
http://www.faq-o-matic.net/2015/12/28/datei-und-freigabeberechtigungen-in-windows/
 
Dort insbesondere ganz unten unter "Die eine Ausnahme".
 
Gruß, Nils