Dunkelmann

Es ging hier ja auch nur darum die Netzwerklast im LAN zu vermeiden. Das das Storage bei jedem Snapshot belastet wird steht außer Frage :cool:

Du solltest auf keinen Fall derartige Experimente mit einem Produktiv Volume durchführen! Wenn du spielen möchtest, erstelle dir ein neues Volume, dass du zur Not kaputt spielen kannst. Genau für das von dir beschriebene Vorhaben sind Storage-Snapshots da. Das Backup und der Datentransfer zum Backupserver laufen komplett im SAN und belasten keine anderen Netze.

Den ASM brauchst du nur für den konsistenten Snapshot deiner Volumes. Hinterher kannst du den Snapshot im Prinzip wie einen x-beliebigen iSCSI Target mit einem Backupsystem deiner Wahl verbinden und die Daten sichern.

Der Equallogic ASM könnte eventuell was sein. Dell EqualLogic - Auto-Snapshot Manager/VMware Edition Funktioniert zumindest unter Hyper-V zuverlässig. Mit VMWare habe ich da leider keine Erfahrungen.

Stimmt, bei neuen Standorten muss man die Standortverknüpfung auswählen. Ich habe das anscheined immer reflexartig mit gemacht. Das Erstellen einer neuen Standortverknüpfung kannst du dir sparen. Wenn dich der Name "DefaulIPSiteLink" stört, kannst du das Objekt umbenennen. Wo schreibt er das? Er schreibt von mindestens zwei Standorten pro Verknüpung.

Glückwunsch! Kannst du uns einen groben Überblick der abgefragten Themen geben?

Letzte Woche hatte ich ein ähnliches Problem. Das Problem war, dass die url: http://update.microsoft.com/redist/wuredist.cab nicht mehr gültig ist. Ich habe den aktuellen Update Client manuell installiert und alles war gut. How to obtain the latest version of the Windows Update Agent

Dann schau dich doch nach anderen Lösungen um. Zwischen € 20,- und € 40,- pro Client und Jahr musst du allerdings schon rechnen. Antimalware und Firewall haben gar nichts miteinander zu tun. Es sind zwei unabhängige Schutzmechanismen für das Netzwerk. Was du benötigst, hängt vom Schutzbedarf und/oder deiner Paranoia ab.

robocopy komprimiert aber nicht ;)

Ganz umsonst: 7-Zip als Batch

Du solltest für alle Subnetze der Domäne eine Reverse Lookup Zone einrichten. Es ist fast egal ob du es vorher oder nacher tust. In der Standardverknüpfung (Default IP Site Link) sind alle Standorte enthalten. Wenn du keine komplexen Topologien hast, besteht keine Notwendigkeit zur Anpassung. Wenn es keine Subnetze und Standorte gibt, solltest du diese anlegen - und zwar alle. Woher soll der DC sonst wissen, dass es ein WAN-Subnetz/Standort ist.

Ein schöner step-by-step guide für eine Test-Cloud: http://download.microsoft.com/download/B/6/2/B62D29FD-4C1D-47C0-AA4D-1E6C898ACBE8/Microsoft%20Private%20Cloud%20Evaluation%20Guide.pdf

Was spricht gegen einen zweiten DPM?

Wenn ihr bereits virtualisiert und mehr als einen Host habt bzw. benötigt, würde ich ernsthaft über eine SAN Lösung nachdenken. Ist zwar etwas teurer, aber mittel- und langfristig die bessere Wahl. Hat der Server keinen Platz mehr zum Einbau, kann ein DAS (Direct Attached Storage) helfen. Ich kenne das HP Produktportfolio zwar nicht so gut, aber die haben so etwas sicherlich auch im Programm.

Vieleicht könnte eine Smartcardlösung helfen. Da jeder MA nur eine hat, kann er auch nur an einem PC die Verbindung initiieren. Wechselt er nun den PC muss er die Card mitnehmen und die Session am TS (und ggf. am Client) wird beim Entnehmen der Smartcard sauber abgemeldet.

Es geht, nur nicht mehr per copy & paste. Configuring Standard User Accounts Creating a Mandatory User Profile Dafür muss der Benutzer lokaler Administrator sein bzw. über Schreibrechte in dem Verzeichnis verfügen.

Eventuell bieten die Applikationen die Möglichkeit für eine Installation auf einem Fileshare. Dann hättest du nur einen Ort an dem die Programme liegen und müsstest den Benutzern nur eine Verknüpfung bereitstellen.

Ich würde bei renitenten Anwendern organisatorische Lösungen anstreben. Unter technischen Lösungen haben i.d.R. auch die MA zu leiden, die die IT nur als Arbeitsmittel nutzen. Eventuell wäre das eine Teststellung wert: UserLock® Access security and concurrent login control for networks

Aus PUR Jan 2008 (Seite 33): Ich muss meinen Irrtum eingestehen. Anscheinend sind die SBS 2003 CAL nicht mehr für aktuelle Server nutzbar.

Gesonderte Server CALs (Egal ob User oder Device) benötigst du nicht da du eine SBS Domäne hast. Du benötigst nur SBS-CALs in ausreichender Anzahl. Beim SQL musst du ermitteln, welche SKU erworben wurde bzw. installiert ist. Dann können wir dir verraten, welche Lizensierung erforderlich ist. Für den TS benötigst du auf jeden Fall RDS-CAL (Device oder User). Das der Lizenzserver mit auf dem TS Läuft ist ok. Wenn ich mich recht erinnere gab/gibt es Probleme 2008'er CALs über einen 2003'er Server zu verwalten. Wenn auf dem TS ein Office 2007 Enterprise installiert ist, muss für alle zugreifenden Clients ebenfalls Office 2007 Enterprise lizensiert sein. (Der Terminalserver benötigt keine zusätzliche Office Lizenz, es wird nur der Client lizensiert)

Es ist nicht wirklich hilfreich, wenn ungenügende Topologieskizzen durch Äußerungen wie "meine Firewall hängt am Domain Controller" ergänzt werden. :confused:

Für Outlook/Exchange sind 4Mibit (oder auch weniger) kein Problem. Die Erstsynchronisierung und das Verschicken/Empfanger großer Mails dauern dann nur etwas länger. Einen zweiten WSUS kannst du an der Lokation aufsetzen. Wenn die Synchronisierung nur außerhalb der Hauptarbeitszeiten erfolgt (z.B. Nachts), sollte es keine Probleme geben. Fat-Client Anwendungen mit SQL Zugriff über schmale WAN Verbindungen machen keinen Spass. Hier wäre eine Remotelösung der eleganteste Weg. (RDS/VDI) Für VOIP wirst du wohl mit QoS Arbeiten müssen. Wenn sich die Daten und deren Bearbeitung strikt trennen lassen, könntest du DFS-R nutzen um die Lokationsdaten Nachts in die Zentrale zu Replizieren und zentral zu sichern. Um Konflike zu vermeiden soltest du die Zentrale als schreibgeschützten DFS-Knoten einrichten.

Port TCP 1745 ist der ISA Client. Und was ist "DC mit ASA"? Reden wir von einer Cisco ASA? Warum werden im internen Netz öffentliche Adressen verwendet? Das Setup sieht etwas wirr aus. Beide Systeme haben jeweils einen Port im 192.5.'er Netz und einen Port im 192.168.'er Netz. Ich vermute stark, es gibt ein Routingproblem und/oder ein Problem mit den Request und Response Pfaden.

Von welchen Programmen sprechen wir hier? Was sagt der Hersteller mit den vielen Updates dazu? Der sollte der erste Ansprechpartner sein und die Fragen am besten beantworten können.

Erstelle dir einfach ein Dummy-Volume für den Failovertest