Microsoft schreibt dazu:

Anhand von Gruppenrichtlinieneinstellungen werden die verschiedenen Komponenten der Desktopumgebung definiert, die durch einen Systemadministrator verwaltet werden, wie z. B. die Programme, die Benutzern zur Verfügung stehen, die Programme auf dem Desktop des Benutzers und die Optionen im Startmenü. Um eine spezielle Desktopkonfiguration für eine bestimmte Benutzergruppe zu erstellen, verwenden Sie den Gruppenrichtlinienobjekt-Editor. Von Ihnen angegebene Gruppenrichtlinieneinstellungen sind in einem Gruppenrichtlinienobjekt enthalten, das wiederum zu ausgewählten Active Directory®-Objekten zugeordnet ist (Standorte, Domänen oder Organisationseinheiten).

Gruppenrichtlinien gelten nicht nur für Benutzer und Clientcomputer, sondern auch für Mitgliedsserver, Domänencontroller und weitere Computer unter Microsoft® Windows® 2000 innerhalb des Verwaltungsbereichs. Standardmäßig betreffen Gruppenrichtlinien, die auf eine Domäne angewendet werden (die also auf Domänenebene direkt oberhalb des Stammverzeichnisses von Active Directory-Benutzer und -Computer angewendet werden), alle Computer und Benutzer in der Domäne. Active Directory-Benutzer und -Computer weist außerdem eine integrierte Domänencontroller-Organisationseinheit auf. Sind Ihre Domänencontrollerkonten an diesem Speicherort gespeichert, können Sie unter Verwendung des Gruppenrichtlinienobjekts Standard-Domänencontrollerrichtlinie Domänencontroller getrennt von anderen Computern verwalten.

Die Gruppenrichtlinien beinhalten Richtlinieneinstellungen für die Benutzerkonfiguration (mit Auswirkung auf Benutzer) und für die Computerkonfiguration (mit Auswirkung auf Computer). Weitere Informationen finden Sie unter Benutzerkonfiguration und unter Computerkonfiguration.
Quelle: Übersicht über Gruppenrichtlinie

Wie von allen Dingen die einem ans Herz gewachsen sind sollte man natürlich auch von den Gruppenrichtlinien regelmäßige Backups erstellen.
Das folgende Skript soll dies automatisieren. Es erstellt in einem anzugebenden Ordner pro Durchlauf einen Ordner mit allen Gruppenrichtlinien und zwei Text Dateien. in der ersten Datei (_Backup.log) wird der Backupvorgang dokumentiert, außerdem ist mit dieser Datei die Zuordnung zwischen Gruppenrichtlinien, Gruppenrichtlinien-ID und der Backup-Id möglich. Das ist insbesondere für die Wiederherstellung der GPOs wichtig. Die zweite Datei enthält alle Verlinkungen der gesicherten GPOs.

Zum Erzeugen der Backups wird der Pfad benötigt an dem die Backups aufbewahrt werden sollen. Erfolgt keine Angabe werden 7 Backups aufbewahrt.

backup-gpo.ps1 C:\backup
Speichert das Backups im Verzeichnis c:\Backup

backup-gpo.ps1 -backupDir \\storagesystem\backup$\GPO -keepBackups 10
Speichert das Backups im Verzeichnis \\storagesystem\backup$\GPO und bewahrt 10 Backups auf

Beispiel 2011-08-05_backup.log [Auszug]:

DisplayName     : Default Domain Policy
GpoId           : 354e6522-016d-11d2-4325-00c04fb984f9
Id              : 982773d3-f421-411b-9753-e23efa9565e1
BackupDirectory : \\storagesysten\backup$\GPO\_backup
CreationTime    : 05.08.2011 02:16:04
DomainName      : dacoweb.org
Comment         : 

DisplayName     : Zertifikatsverteilung
GpoId           : 354e6522-8843-42b0-2a3b-2737dd308c1a
Id              : 987ef322-f1a5-487d-6d3c-85363ff9bb33
BackupDirectory : \\storagesystem\backup$\GPO\_backup
CreationTime    : 05.08.2011 02:16:06
DomainName      : dacoweb.org
Comment         : 

DisplayName     : Default Domain Controllers Policy
GpoId           : 982dc2b2-016f-11d2-945f-00c04fb984f9
Id              : 324e212f-013b-413c-a8dc-051b21a69ebd
BackupDirectory : \\storagesystem\backup$\GPO\_backup
CreationTime    : 05.08.2011 02:16:07
DomainName      : dacoweb.org
Comment         :

DisplayName     : Servereinstellungen
GpoId           : 2765d423-8843-42b0-2a3b-233bb2938322
Id              : 987ef322-f1a5-487d-6d3c-23343fd26545
BackupDirectory : \\storagesystem\backup$\GPO\_backup
CreationTime    : 05.08.2011 02:16:08
DomainName      : dacoweb.org
Comment         :

Beispiel 2011-08-05_links.log [Auszug]:

DistinguishedName        : OU=Domain Controllers,DC=dacoweb,DC=org
LinkedGroupPolicyObjects : {cn={982dc2b2-016f-11d2-945f-00c04fb984f9},cn=polici
                           es,cn=system,DC=dacoweb,DC=org}

DistinguishedName        : OU=Administration,DC=dacoweb,DC=org
LinkedGroupPolicyObjects : {}

DistinguishedName        : OU=Adminkonten,OU=Administration,DC=dacoweb,DC=org
LinkedGroupPolicyObjects : {}

DistinguishedName        : OU=Server,OU=Administration,DC=dacoweb,DC=org
LinkedGroupPolicyObjects : {cn={2765d423-8843-42b0-2a3b-233bb2938322},cn=polici
                           es,cn=system,DC=dacoweb,DC=org, cn={354e6522-8843-42
                           b0-2a3b-2737dd308c1a},cn=policies,cn=system,DC=dacow
                           eb,DC=org}

<#
    .SYNOPSIS
    Erstellt ein Backup der Gruppenrichtlinienobjekte
    .Description
    Das Script erstellt Backups der Gruppenrichtlinienobjekte im angegeben Verzeichnis (BackupDir).
    Dazu werden im angegeben Verzeichnis pro Backup  ein Unterordner angelegt.

    Der optionale Parameter -BackupPrefix kann genutzt werden um den Namen der Unterordner anzupassen.
    Durch Angabe des Parameters -keepBackups kann die Anzahl der aufbewahrten Backups konfiguriert werden.
    Standardmäßig werden 7 Backups aufbewahrt
    .Notes
    Es werden die Module ActiveDirectory und GroupPolicy benötigt
    .Example
    backup-gpo.ps1 C:\Backup
    Speichert das Backups im Verzeichnis c:\Backup
    .Example
    backup-gpo.ps1 -backupDir C:\Backup -keepBackups 10
    Speichert das Backups im Verzeichnis c:\Backup und bewahrt 10 Backups auf
#>
PARAM(
    [Parameter(Position=0,Mandatory=$true,HelpMessage="Zielverzeichnis des Backups",ValueFromPipeline=$false)][string]$backupDir,
    [string]$BackupPrefix="daily",
    [int]$keepBackups=7
)

### No configuration needed below this point ###
Import-Module GroupPolicy,ActiveDirectory

$currentBackupDir = ($BackupDir + "\_backup")
write-host "Create Backup: " $currentBackupDir

new-item -type directory ($currentBackupDir) | out-null

$mydate = get-date -uformat "%Y-%m-%d"
backup-gpo -all -path $currentBackupDir | out-File ($currentBackupDir + "\" + $myDate + "_backup.log")
Get-ADOrganizationalUnit -filter "Name -like '*'" | fl DistinguishedName,LinkedGroupPolicyObjects | out-file ($currentBackupDir + "\" + $myDate + "_gpo-links.txt")

$removeBackup = $backupDir + "\" + $backupPrefix + ($keepBackups-1)
if (test-path($removeBackup)) {
    write-host "Remove Backup " $removeBackup
    remove-item ($removeBackup) -Confirm:$false -Recurse
}

write-host "Rotate Backups"
for($i=$keepBackups;$i -gt -1;$i--) {
    if (test-path($backupDir + "\" + $backupPrefix + $i)) {
        move-item -path ($backupDir + "\" + $backupPrefix + $i) -destination ($backupDir + "\" + $backupPrefix + ($i+1))
    }
}

move-item -path ($currentBackupDir + "\") -destination ($backupDir + "\" + $backupPrefix + 0 + "\")

Weiterführende Informationen zum Thema Gruppenrichtlinien:

• MSXFAQ.de - Gruppenrichtlinien: http://www.msxfaq.net/verschiedenes/gpo.htm
• Gruppenrichtlinien - Übersicht, FAQ und Tutorials: http://www.gruppenrichtlinien.de/

• Lokales Logging auf einen Datastore
  Das lokale Logging kann am ESX in den Erweiterten Einstellungen (Konfiguration -> Software -> Erweiterte Einstellungen) konfiguriert werden. Die Option heißt: Syslog.Local.DatastorePath

  Set-VMHostAdvancedConfiguration -VMHost (get-vmhost "ESX1" -Name "Syslog.Local.DatastorePath" -Value "[Datastore] messages.log

• Remote Logging
  Hier sind wieder zwei Möglichkeiten denkbar, wobei ich hier nur letztere kurz beschreibe
  • Nutzung der vi-Logger Funktionalität der vMA (vSphere Management Appliance)
  • Remote Syslog

Das Remote-Logging kann am ESX in den Erweiterten Einstellungen (Konfiguration -> Software -> Erweiterte Einstellungen) konfiguriert werden. Die Option heißt: Syslog.Remote.Hostname
Im Einfachsten Fall dort die IP-Adresse des Remote Log Hosts eintragen.

Oder per PowerCLI:

Set-VMHostAdvancedConfiguration -VMHost (get-vmhost "ESX1" -Name "Syslog.Remote.Hostname" -Value "[Datastore] messages.log

Auf dem Zielsystem ist die Konfiguration abhängig vom verwendeten Syslog Daemon.

Am Beispiel rsyslogd:
Zunächst muss der Empfang von Syslog Messages per UDP oder TCP aktivert werden. Dazu wird die Datei /etc/rsyslog.conf angepasst.

# UDP Empfang
$ModLoad imudp
$UDPServerRun 514

# TCP Empfang
#$ModLoad imtcp
#$InputTCPServerRun 514

Da es aber mit der Zeit recht unübersichtlich wird, wenn sich die Meldungen der ESX Server und die des Syslog Servers miteinander vermischen, kann pro System auch eine eigene Datei angelegt werden. Dazu legt man zunächst unter /etc/rsyslog.d/ eine neue Datei 40-RemoteLog.conf mit folgendem Inhalt an:

$template DynaFile,"/var/log/system-%HOSTNAME%.log"
:source , isequal , "esx1" ?DynaFile
:source , isequal , "esx1" ~

Die zweite Zeile erwirkt die Umleitung der Meldungen in das neue Logfile, die dritte Zeile beendet die weitere Bearbeitung (sonst würden die Logmeldungen ja doch wieder in der messages des Syslog Servers landen).

Ob alles funktioniert findet man durch warten (bis der ESXi was loggt) oder durch den Befehl logger Testmeldung an der ESXi Konsole heraus.

Aktiviert wird das Debugging (als Nutzer Zimbra) wie folgt:

postconf -e debug_peer_list=mail.dacoweb.org
postconf -e debug_peer_level=3
postfix reload

Danach wird ein vollständiges Log der Kommunikation zwischen den beteiligten Mailserver nach /var/log/mail.info geschrieben.

Daraus lassen sich dann sehr oft Rückschlüsse treffen warum der Mailversand nicht funktioniert bzw. ob ein Feature wie TLS verwendet wird oder nicht.

Das Debug Logging sollte aber danach schnellst möglich wieder deaktiviert werden.

postconf -e debug_peer_list=
postconf -e debug_peer_level=1
postfix reload

Nun habe ich bei dacoweb.org Emailadressen die nicht vom ZCS verwaltet werden sollen und direkt per IMAP vom Providerserver genutzt werden. Leider stellt sich dabei zunächst das Problem, dass der ZCS (berechtigterweise) sich für die gesamte Email-Domain dacoweb.org zuständig fühlt.

Abhilfe schafft hier entsprechende Transport-Regeln für den integrierten Postfix MTA zu bauen.
Hierzu findet man eine gute Starthilfe im Zimbra Wiki.

Leider hat es sich als sehr unpraktisch erwiesen das transportsfile unter /opt/zimbra/postfix/conf/ abzulegen, da bei einem Update (in diesem Fall auf 7.1.1) offensichtlich das gesamte Verzeichnis /opt/zimbra/postfix/conf/ ersetzt wird. Dies führt unweigerlich dazu, dass nach dem Update keinerlei Mails mehr von Postfix verarbeitet werden.

Jul 11 23:22:48 zcs postfix/trivial-rewrite: fatal: open database /opt/zimbra/postfix/conf/transportfile.db: No such file or directory
Jul 11 23:22:49 zcs postfix/master: warning: process /opt/zimbra/postfix/libexec/trivial-rewrite pid 25575 exit status 1
Jul 11 23:22:49 zcs postfix/master: warning: /opt/zimbra/postfix/libexec/trivial-rewrite: bad command startup -- throttling

Nachdem ich das Transportsfile neu angelegt habe (diesmal direkt unter /opt/zimbra/conf) und ich Postfix entsprechend neu konfiguriert hatte, war auch der Mailversand wieder problemlos möglich.

Auf der Seite LANbugs.de hab ich aber ein handliches Skript gefunden.
http://www.lanbugs.de/netzwerktechnik/hp-procurve-bash-backup/

Die Kommunikation zum Switch erfolgt über SNMP, die Config wird per TFTP kopiert und mit ordentlichen Dateinamen abgespeichert.