Dunkelmann

Eine kleine Sammlung zum Thema - ohne Anspruch auf Vollständigkeit :cool: System Center Data Protection Manager: Pricing and Licensing DPM Licensing System Center Data Protection Manager: Protect Your Virtualized Environments

Das ist durch die Enterprise abgedeckt - sofern diese nicht anderweitig verwendet werden. Die Anzeige im DPM dient lediglich der Orientierung.

Das Lizenzmodell ist recht einfach: Für eine Dateisystemsicherung ohne Anwendungen wird die Standardlizenz benötigt. Mir bekannte Anwendungen per Microsoft Definition sind: - Exchnage - SQL - Hyper-V - Sharepoint Für die Sicherung dieser Anwendungen per DPM wird eine Enterpriselizenz benötigt. Für Hyper-V gilt: Wird nur der Host gesichert, reicht eine Standardlizenz. Sollen die VMs über den Host gesichert werden, wird für den Host eine Enterpriselizenz benötigt. Sollen die VMs direkt über den DPM und nicht über den Host gesichert werden, gilt a) eine Standardlizenz je VM ohne Anwendungen b) eine Enterpriselizenz je VM mit Anwendungen c) eine Enterpriselizenz für den Host erlaubt die Sicherung des Hosts und die direkte Sicherung von 4 VMs mit oder ohne Anwendungen über den DPM d) eine Datacenter Lizenz (enthalten in der Server Management Suite Datacenter) erlaubt die Sicherung des Hosts und die direkte Sicherung beliebig vieler VMs auf dem Host.

Um auf die internen SBS Ressourcen zuzugreifen muss sich der externe Benutzer mit einem entsprechend berechtigtem Konto aus der SBS Domäne anmelden. Wenn dem Externen interne Anmeldeinformationen bekannt sind, gibt es ein ganz anderes Problem. Die Sicherheitsrichtlinien (ungültige Anmeldeversuche, Kontosperrung etc.) sollten auf jeden Fall aktiviert sein, wenn der Server von Außen erreichbar ist. Ansonsten ist es ein Leichtes, per Brute Force den Server zu kompromittieren.

Ich hab's bei mir umgekehrt gelöst. Ich wollte keinen dyndns Agent auf meinem Server haben. Vor der ASA sitzt ein einfacher NAT Router (Fritz Kiste) der die Verbindung aufbaut und den dyndns Eintrag aktualisiert. Dahinter läuft die ASA. Auf der Fritz Kiste sind die entsprechenden Portweiterleitungen für VPN etc. zur ASA eingerichtet.

Moin, ich habe ein kleines Phänomen bei unseren zwei DPM2010 Servern. Der erste DPM sichert alle Server Systeme und den zweiten DPM samt SQL Datenbank. Der zweite DPM sichert nur den ersten DPM samt SQL Datenbank. Im DPM Status-Report erscheint auf beiden Systemen die Meldung, dass die DPM Datenbank nicht geschützt ist, obwohl die Sicherung ohne Probleme läuft. Laut SQL Management Studio ist in der Datenbank das korrekte Datum der letzten Sicherung eintragen. Hat jemand eine Idee was den Servern fehlt oder handelt es sich dabei um ein bekanntes "Feature"?

Das ist reine Philosophie. Bei uns sind nicht so viele Tray Programme im Umlauf und die werden alle eingeblendet. - Netzwerkstatus - Audio - Antivirus - Offlinedateien - BGInfo als Tray (Ideal für Remoteunterstützung) - Eventuell noch die Grafikkaten Steuerung, wenn eine dabei ist Nur das Wartungscenter ist deaktiviert, da ich bisher noch keine Möglichkeit gefunden habe, die Warnung zum nicht geplanten Backup zu deaktivieren und jede nicht bearbeitete Problemmeldung den Durchschnittsanwender verwirrt oder abstumpfen lässt.

Genau das sollte Dir eigentlich Dein Backupprogramm sagen. Ist die Software überhaupt für W2008 freigegeben? repadmin /showbackup

Warum das? Dafür gibt es den Remotedesktop Webzugriff. OWA und RDweb haben im IIS einen eigenen Pfad "https://domain.tld/OWA" und "https://domain.tld/....." und können somit direkt und unabhängig voneinander angesprochen werden.

Du hast nicht geschrieben, was für Platten verbaut werden sollen. SAS oder SATA? Bei 15k SAS würde ich einen RAID5 bauen, bei 7,2k SATA einen RAID10

Hmmm, dann hab' ich wohl seit drei Jahren massive Halluzinationen und das ohne bewustseinserweiternde Hilfsmittel :D

Das Farmzertifikat kannst Du über das MMC Zertifikate oder die Webregistrierung anfordern. Dabei musst Du eine benutzerdefinierte Anforderung erstellen. ---- Auch wenn das Ganze nur intern verwendet werden soll, solltest Du Brian Komars "PKI and Certificate Security" vor dem Aufsetzen wenigstens überflogen haben.

Die Windows Firewall ist für die meisten Zwecke ausreichend. Es muss keine Zusatzsoftware getestet, angeschafft, installiert und verwaltet werden. Die Einstellungen lassen sich relativ simpel per GPO verteilen. Wie bei jeder Firewall gehört natürlich eine Testphase vor dem scharfschalten dazu.

Der SIM ist nur für das Deployment zuständig. Für die meisten Deiner Punkte gibt es Gruppenrichtlinien (Domäne oder lokale) und/oder den Default User. Du kannst Dir auch einen Referenz PC vorbereiten, konfigurieren, mit sysprep versiegeln und auf einem WDS aufzeichnen.

Ein SBS 2008 sollte einen RODC 2008 ohne Probleme unterstützen. Ab Funktionsebene Windows 2003 wird der RODC unterstützt und in diesem Modus läuft der SBS. Mit etwas Glück kannst Die den RODC mit dcpromo herunterstufen. Funktioniert das nicht, währe der nächste Versuch, das Computerkonto aus der OU Domain Controllers zu löschen. Ich vermute aber, dass Deine SBS Domäne bzw. der SBS selbst noch andere Probleme hat.

Was für ein VPN Gateway steht am anderen Ende? Bei Cisco hatte ich bisher keine Probleme, der Client holt sich die Routingkonfiguration vom Gateway und benötigt - außer bei der Installation - keine Admin-Rechte. Ein paar mehr Infos könnten die Diagnose erleichtern. - Sind die Routen auf dem VPN Gateway korrekt gesetzt? - Gibt es noch eine Firewall - eventuell im Gateway integriert - zwischen VPN und LAN? - Welche Ergebnisse liefern ipconfig -all und route print? - Hat der VPN Client ein Log, wenn ja bitte posten?

Ab 2008 gibt es anscheinend neue Spielregeln DNS: DNS servers on <adapter name> should include their own IP addresses on their interface lists of DNS servers

Genau andersrum soll es laut Best Practice Analyzer sein. 1. DNS Server - anderer (schreibbarer) DC 2. DNS Server - 127.0.0.1 Zu dem eigentlichen Problem: Die Credentials administrativer Konten sind per default von der Zwischenspeicherung auf einem RODC ausgenommen. DFS und Namespace Veröffentlichung laufen wunderbar auf einem RODC. Die Active Directory Standorte und Subnetze müssen nur sauber gepflegt sein.

Für einen File Server auf jeden Fall. Besonders mit dem Ressourcenmanager und Quoten kann man seine Anwender schön quälen .... ich meine natürlich zum sparsamen Umgang mit Betriebsmitteln motivieren :P

Ein Zertifikat bekommst Du von einer Zertifizierungsstelle. Theoretisch in zwei bis drei Tagen installiert und betriebsbereit. Praktisch gehöhrt dazu allerdings ein PKI-Konzept, das schon mal 6 bis 12 Monate Vorlauf benötigen kann. Alles Andere ist Frickelei und macht Dir früher oder später das Leben schwer. Eine einfache Lösung gibt es auch: 1. Die RDP-Verbindung anpassen - Benutzerdefinierte Einstellungen: authentication level:i:0 2. GPO Administrative Vorlagen/System/Delegierung von Anmeldeinformationen/Delegierung von Standardanmeldeinformationen mit reiner NTLM-Serverauthentifizierung zulassen Hier die Terminal Server eintragen

Zu robocopy gib't eine sehr gute Dokumentation. ca. 100 Seiten. Für die meisten Aktionen reicht mir dieser Aufruf: robocopy [Quelle] [Ziel] /copyall /mir /zb /r:5 /w:5 /log:[Logfile mit Pfad] Quelle und Ziel: lokaler oder UNC Pfad copyall: Übernimmt alle Dateiattribute mirror: Spiegelt den gesamten Verzeichnisbaum der Quelle zb: Backupmodus (kopiert auch Dateien mit Filelock) retry: anzahl der Wiederholungen bei Fehler wait: wartet bei Fehler 5 Sekunden bis zum nächsten Versuch log: logdatei mit dem Ergebnis des Kopiervorgangs Die Dateiserverrolle ist nur auf Dateiservern notwendig bzw. sinnvoll. Einfache Freigaben bzw. der Zugriff auf administrative Freigaben funktionieren auch ohne.

Meine Gedanken: - Den TMG müssen die beiden LAN und die Transportnetze zur Sonic bekannt gemacht werden. LAN als intern, Transport als DMZ(Umkreis) - Zwischen dem LAN und dem Transportnetz muss das Verhältnis als "Routing" definiert werden. - Die Sonic benötigt jeweils eine statische Route, die den TMG als Gateway für das dahinterliegende LAN setzt. - Ein wenig Feinabstimmung bei den Firewallregeln, dann sollte es funktionieren. Ob das Szenario "oversized" ist, hängt vom Schutzbedarf ab. Grundsätzlich ist es aber ein guter Ansatz zwei Firewalls von zwei verschiedenen Herstellen zu verketten.

Für die Anmeldung: administrator@FQDN Mit dem Administrator sollte jedoch niemand in einer Produktivumgebung arbeiten. Idealerweise ist das Konto immer deaktiviert und das Kennwort im Tresor hinterlegt. Jeder Admin sollte sein eigenes Konto mit den notwendigen Rechten bekommen - auch wenns nur einen Admin in der Firma gibt.

Probier mal OTRS aus. OTRS::Open Source Trouble Ticket System - Service Support System::Welcome! Das ist zwar in erster Linie ein Ticketsystem, kann aber bei entsprechnder Konfiguration auch als Logbuch genutzt werden.

Prinzipiell kann jeder Benutzer, der sich am Terminal Server anmelden darf, jede Anwendung starten. Dabei ist es egal ob er den Desktop zu sehen bekommt oder nur eine RemoteApp. Selbst wenn er nur die RemoteApp präsentiert bekommt, kann er sich jederzeit manuell über den RDP Client auf dem TS anmelden und bekommt den vollen Desktop! Der TS muss also noch über entsprechende GPO gehärtet werden! Stichworte: Zugriff auf Systemsteuerungselemente, lokale Laufwerke, mandatory profiles usw. Da Dein TS mehrere Anwendungen hosted, kannst Du auch kein Startprogramm bei der Anmeldung über GPO, Benutzerprofil oder Serverkonfiguration vorgeben. Der einzig sinnvolle Weg ist es, die Verzeichnis ACLs auf dem TS entsprechend zu bearbeiten oder je Anwendung einen eigenen TS zu betreiben.