Dukel

Den Hyper-V Host braucht man nicht sichern. Der ist schneller neu installiert. Veeam sichert die Konfiguration immer extra. In den Optionen (Configuration Backup) legt man fest wohin das gesichert wird und wie lange es aufbewahrt wird.

Statt DNS Round-Robin kann man auch einen Loadbalancer einsetzen. Hat dann nicht die Nachteile von DNS-RR.

Löscht du die Dateien zwischen den Versuchen?

Evtl. wenn das Webinterface und Gateway wichtig sind, dann 2x RD-Web und 2x RD-Gateway. Das Gateway kommt, wie schon erwähnt, extra. Diese sollte auch in die DMZ oder einen anderen Sicherheitsbereich und nicht in das interne Netzwerk. Btw. für einen Redundanten Broker brauchst du auch eine zentrale Datenbank und diese sollte dann auch Verfügbar aufgesetzt werden.

Mindestens der Verbindungsbroker sollte Hochverfügbar aufgesetzt werden. Brauchst du das Gateway?

Deswegen gibt es das Syntetic Full. Welches aus den ganzen Inkrementals ein neues Full baut. Ich möchte keine regelmäßigen Full Backups mehr machen. Bei Veeam kann man auch Active Full Jobs machen, wenn es nicht anders geht!

Wir haben bei Kunden Yubikeys im Einsatz. Vielleicht gibt es dort etwas passendes.

Wieso das? läuft bei vielen Kunden mit unterschiedlichen Backupprogrammen problemlos.

Hier ging es um die Problematik mit defekten Inkrementals nicht um Replikation. Leider habe ich mit der Replikation nur theoretische Erfahrung, da ich das bei keinem Kunden bisher einsetze.

Dafür nutzt man ReFS. Dabei schaut ReFS nach Defekten Blöcken. Jein. Wenn man DFSR nutzt um Daten von einem Standort zu einem anderen zu replizieren und sie dann dort zu sichern ist das vergleichbar. Wenn man aber DFSR nutzt um Fileshares zu replizieren um von beiden Standorten drauf zuzugreifen ist das etwas anderes. DFSR und Veeam Replication sind zwei verschiedene Dinge! Daher werden (wie bei Forever Incremental Techniken bei anderen Herstellern) regelmäßig Jobs gestartet, die aus den vielen Backups ein neues Full erstellen. Dies belastet dann nicht die Produktion sondern nur den Backupserver.

Es kommt drauf an, was der Kunde beauftragt hat. Wenn er keine Benachrichtigung wollte oder keine Transition gemacht wurden, nachdem die Prüfung nicht mehr gewünscht war sehe ich den DL nicht in der Schuld.

Geht eine DAG überhaupt mit der Umlaufprotokollierung?

Wieso sollten einzelne Gruppen unterschiedliche Vorlagen bekommen? Das möchte man alles mit Gruppen umsetzen!

Wieso temporär? Migriere den Exchange einfach in die neue Lösung (imap beim Provider). Mit dem Pop Connector ist das doch richtig einfach. Diesen einfach deaktivieren und alle Clients umstellen.

Ich würde das nicht machen und der Mitarbeiter soll sich per Imap auf den Exchange verbinden.

Wenn oben nur der Chef zugriff hat, wo greifen die Benutzer dann zu, wenn diese keine Berechtigungen haben? Auch die Ordner / Sharestruktur würde ich nicht nach der Firma aufbauen, sondern nach den "Business Needs". Es gibt die Möglichkeit, dass jede Abteilung einen Bereich bekommt oder es gibt generelle Bereiche und darunter wird es wild oder es gibt generelle Bereiche und darunter eine Ebene mit den Abteilungen oder... oder ... oder. Hier ist auch sinnvoller die Berechtigungsstrukturen flach zu halten. 1-2 Ebenen in denen die Berechtigungen vergebene werden und darunter müssen die Bereiche sich Organisieren. Und bei den Berechtigungen auch nicht Teamweise sondern Rollenbasiert. Das lässt sich mittels https://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/ (AGDLP) umsetzen.

Bei uns sind es ingesamt drei Ebenen. Nicht drei ebenen von Usern. Firma/Bereich -> Users -> Groups -> Clients -> Desktops -> Clients -> Laptops -> Servers ... Eine OU-Struktur (und auch Ordnerstruktur) muss nicht auf ewig da stehen. Diese kann man auch ändern!

Die OU Struktur sollte nicht nach der Firma sondern nach der Administration erfolgen. Wenn ein Mitarbeiter die Abteilung wechselt will man diesen nicht in den OU's umziehen sondern die Gruppen anpassen. Zu viele Ebenen klingt nach dem falschen Konzept. Bei meinen Kunden sind das max. 3 Ebenen bei den Umgebungen, die ich mit aufgebaut habe. Evtl. hilft ja auch ein Tool wie 8Man dabei.

Hier geht es um einen AD Controller als Core Installation und nicht um einen DB2 Server. Man muss ja nicht alle Dienste als Core Installation machen. Es bietet sich dort an, wo man remote Administriert (AD, SQL Server, Hyper-V, Exchange (ab 2019!)). Mit Server 2019 kommen auch mehr Gui Tools in den Core (nachinstallierbar), z.B. Eventviewer, Explorer, Registry.

Man kann auch andersherum fragen. Was soll eine Gui auf einem DC?

Du kannst eine Shared Mailbox einrichten (Ohne Autoconnect!) und danach den Kalender dieser Shared mailbox öffnen. Da musst du ja nicht das komplette Postfach einhängen.

Oder du nutzt die Variable $PC und gibst diese vor der CIM Abfrage aus.

FT heisst Format-Table und ist für die Ausgabe zuständig. Du kannst mit .property auf einzelne Properties zugreifen: (Get-ADComputer -Filter 'Name -like "xx*-S"' -Properties Name).Name # der Name wird standardmäßig ausgegeben. Es reicht: (Get-ADComputer -Filter 'Name -like "xx*-S"').Name Alternativ kannst du das komplette Objekt übergeben und die Properties in der Schleife nutzen: $PCListe = Get-ADComputer -Filter 'Name -like "xx*-S"' ForEach ($PC in $PCListe) { Copy-Item -Path "\\$($PC.Name)\c$\xxx\xxx\xxx.ini" -Destination "\\server\xxx\xxx\$($PC.Name).xxx.ini" }

Das geht prinzipell so, aber dein $os beinhaltet ein Array von WMI Ergebnissen. $os.ConvertToDateTime($os.LastBootUpTime) wird so nicht gehen. $os | % {$_.ConvertToDateTime($_.LastBootUpTime)} Dein Fehler "RCP Server ist nicht verfügbar" hat einen anderen Grund.

Die 145 Rechner möchte man nicht in das Script oder eine Datei schreiben sondern aus einem Verzeichnisdienst / Datenbank (CMDB) auslesen.