Babble

Hallo Jiri, Bingo. Der User-ID-Agent läuft bei uns auch. Welche Version hast Du installiert? Bei uns läuft noch die Version 4.1.5.

Hallo ChrisRa, versuch mal zwei Backslash vor die IP zu packen: \\a.b.c.d. LG, Babble

Warum verteilst du den Proxy nicht per wpad? Die Option 252 im DHCP und ein entsprechender Eintrag im DNS versorgen dann alle bekannten Browser mit der Proxy-Konfiguration. Siehe: http://www.gruppenrichtlinien.de/artikel/proxykonfiguration-wpad-als-alternative/ LG, Babble.

Hallo Baumpaul, du kannst, wie Jan schrieb über AD Standorte den Zugriff steuern. Du kannst zusätzlich in den Eigenschaften des Namespaces unter Erweitert den Haken bei "Ziele außerhalb des Clientstandortes ausschließen" setzen. In den Eigenschaften der Replikationsgruppe kannst du den Zugriff auch noch einschränken, allerdings kann ich die Option erst am Montag nachschauen. LG, Babble.

Hallo Moschi76, kannst Du keine bedingten Weiterleitungen oder Stub-Zonen nutzen? LG, Babble.

Nicht Der DC, sonder die DCs. Einer der beiden ist gerade frisch installiert. Beide Systeme protokolieren diesen Fehler seit Monaten. Er ist eigentlich nur nervig, da das Ereignisprotokoll zugemüllt wird. Ich habe derzeit keinen direkten Zugang zu den Servern, diese stehen im gesicherten RZ in abgeschlossenen Schränken. Um sicher zu gehen werde ich kurzfristig beide betroffenen Systeme mit einer entsprechenden CD prüfen. Bitte nicht an der IP festmachen! Diese war nur zufällig drin. Insgesamt sieht das so aus: Fehler 14.05.2013 11:11:10 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:07 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:06 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:06 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:06 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:05 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:04 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:04 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:03 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:03 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:02 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:02 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:01 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:01 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:00 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:00 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:00 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:58 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:57 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:57 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:54 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:54 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:52 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:52 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:51 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:51 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:50 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:49 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:49 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:48 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:48 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:48 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:46 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:44 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:43 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:39 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:39 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:39 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:37 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:37 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:36 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:35 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:35 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:34 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:33 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:31 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:30 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:28 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:28 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:27 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:27 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:26 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:25 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:25 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:23 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:23 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:22 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:22 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:22 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:21 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:20 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:20 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:20 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:19 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:18 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:17 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:17 DistributedCOM 10009 Keine wobei jede Zeile eine andere IP als Ziel hat, sowohl intern als auch externe Adressen. Ziele sind ThinClients, Drucker, Notebooks, PC etc. Das deaktivieren des Logging ist ein Workaround, damit die Chance besteht, wichtige Einträge zu lesen. Der Fehler ist damit nicht behoben. Und nein, der DC ist aus dem Internet nicht erreichbar. LG, Babble.

Der DC ist sauber. Das Problem ist auch nur auf den beiden physikalischen 2008R2-DCs. Die virtuellen und die 2003R2-DCs haben das Problem nicht. Wenn man mit Procmon das ganze verfolgt, so kommt man zu svchost als verantwortlichem Prozess ( :() und dort zu OLE, welche den Key HKLM\SOFTWARE\Microsoft\OLE\ActivationFailureLoggingLevel abfragt. Diesen Schlüssel auf 2 (dword) schaltet das Logging für DCOM aus, so das das Systemprotokoll wieder lesbar wird. Ist zwar keine Lösung, aber immerhin ein Workaround... @Zahni: Die IP-Adresse war Zufall, ich habe einfach nur eine Zeile aus dem Systemprotokoll kopiert...

Im Eventlog taucht nur der Fehler DistributedCOM, Ereignis-ID 10009 auf: DCOM konnte mit dem Computer "193.46.63.181" unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen. Leider kein Hinweis auf eine bestimmte Komponente.

Das sehe ich auch so. Die Frage ist, warum er überhaupt mit allen ihm bekannten System irgendwelche Daten austauschen möchte. Ich bin morgen wieder vor Ort und suche mal ob ich einen Hinweis auf eine Komponente finde, bisher war meine Suche erfolglos. Die Adressen sind unterschiedlich. Wie gesagt, er möchte mit internen und externen Adressen kommunizieren, alles was er so kennt. Ein zweiter DC produziert diesen Fehler ebenfalls, die restlichen DCs nicht. Ich tippte auf einen Treiber o.ä. und habe auch deshalb einen der betroffenen DCs schon neu installiert - allerdings nur mit der minimalsten Treiberausstattung, die möglich war. Trotzdem kam nach der Neuinstallation diese Fehlermeldung wieder... LG, Babble.

Hallo Zahni, der DC initiiert die Anfragen, Die Anfragen kommen vom DC und laufen anscheinend gegen alle IP-Adressen, die er so kennt. Und da er auch DNS-Server ist, kennt er ziemliche viele IP-Adressen :). Der DC ist DNS-Server, DHCP-Server und natürlich DC. Sonst nix. LG, Babble.

Hallo zusammen, auf unseren beiden physikalischen DCs (Server 2008R2, SP1, alle Updates) wird das Systemprotokoll im Sekundentakt mit Fehlern geflutet. Quelle: DistributedCOM, Event-ID 10009. Die Fehlermeldung lautet: DCOM konnte mit dem Computer "a.b.c.d" unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen. Die IP-Adressen sind sowohl interne als auch externe IP-Adressen aus dem Internet. Der Fehler tritt schon seit mehreren Monaten auf, diverse Tipps von Google sind schon testet worden. Meistens geht es dabei um SBS 2008 oder um falsch konfigurierte DCOM-Komponenten, was in meinem Fall nicht wirklich zu passen scheint. In der letzten Woche habe ich einen der beiden DCs neu installieren müssen, der Fehler trat nach kurzer Zeit wieder auf. Es existieren noch vier weitere DCs, davon zwei mit Server 2008R2 SP1 als virtuelle Maschinen und zwei als Physik mit 2003 R2, die diese Fehler nicht protokollieren. Auf den betroffenen Systemen ist außer DNS, DHCP nur noch der Palo Alto Agent installiert, eine Deinstallation brachte auch keine Besserung, insbesondere da dieser Dienst auf den nicht betroffenen System auch installiert ist. Hat jemand 'ne Idee? LG, Babble.

Ich fand immer die IBM Redbooks sehr gut: Introduction to Storage Area Networks and System Networking: IBM Redbooks | Introduction to Storage Area Networks and System Networking und das Storage Kompendium: http://www-03.ibm.com/systems/data/flash/de/resources/ibm_storage_compendium_de.pdf Da dürfte auch was zur Geschichte der SANs drinstehen. LG, Babble

Hi. Das ist das normale Verhalten. Das Benutzerprofil wird bei Anmeldung auf den TS kopiert und nach Abmeldung wieder auf den Server zurück. Gruss, Babble.

Zur Größe des Stagingbereichs: Edit the Quota Size of the Staging Folder and Conflict and Deleted Folder War mir jetzt auch noch nicht so geläufig... LG, Babble

Hallo zetor, wenn eine schon replizierte Datei geändert wird, so werden nur die Änderungen übertragen. Dadurch hast du eine Veringerung im Datenvolumen. DFS-R repliziert nur geschlossene Dateien, daher werden in dem iTunes-Verzeichnis nicht alle Dateien repliziert. Das Staging-Device ist - afaik - als Puffer bei der Replikation von Nöten. 100GB halte ich für großzugügig bemessen. Wird also ausreichen :) LG, Babble