Dukel

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.

Schau dir mal die Schleifen an und das auslesen des AD. https://docs.microsoft.com/en-us/powershell/module/addsadministration/get-adcomputer?view=win10-ps https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/foreach-object?view=powershell-6 Zur WMI Abfrage. Wie hast du das in die Variable geschrieben?

Jeweils die Hilfe der Programme aufrufen. Ich mache das meist andersrum. Wenn ich ein Problem habe schaue ich welches Tool ich dafür verwende. Ich muss nicht wissen, was es alles bei Windows schon gibt.

Außerdem sollten die Benutzerdaten nicht ins Profil sondern höchstens (am besten eh direkt auf den Server oder eine entsprechende Applikation) in die Eigenen Dateien, die man per Ordnerumleitung auf den Server umleiten kann.

dir c:\Windows\System32\*.exe

Warum ist die SLA futsch, wenn du dich auf dem Gerät einloggst?

Wieso muss das Profil auf dem Server gespeichert werden? Was ist so wichtig an diesem?

Bei meinem Beispiel braucht man das Array auch nur, wenn man die Dupletten entfernen möchte. Wenn man dies ignorieren kann oder im Nachhinein machen kann, kann man die Adressen direkt in der Schleife ausgeben / in eine Datei schreiben.