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.

Wie hast Du festgestellt dass der DC sauber ist?

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.

Ein DC greift  normalerweise nicht auf Server zu, die  zum Tracken beim Surfen genutzt werden.

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.

Wenn der  DCOM mit  einer  "externen" IP-Adresse keine Daten austauschen konnte, hat das eher nichts mit DNS zu tun.

Das sehe ich auch so. Die Frage ist, warum er überhaupt mit allen ihm bekannten System irgendwelche Daten austauschen möchte.

Nochmals die Frage  welche DCOM-Komponente  nicht  mag (sollte im Eventlog stehen).

Ich bin morgen wieder vor Ort und suche mal ob ich einen Hinweis auf eine Komponente finde, bisher war meine Suche erfolglos.

Welche Adressen  aus  dem Internet sind denn betroffen ?

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

For the initial replication of existing data on the primary member, the staging folder quota must be large enough so that replication can continue even if multiple large files remain in the staging folder because partners cannot promptly download the files.

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

Das ist so richtig. Es gibt ja kein "\\domainname\FS" im Sinne einer Freigabe. Also darf dort nicht geschrieben werden. Das wird bei der Einrichtung des Stammes auch so festgelegt.

Nur das Ziel "\\domainname\FS\location01-folder01" ist ja ein eine Freigabe. Dort kann dann geschrieben werden.

LG, Babble.

Hallo muluske,

ich hatte dies Problem mal mit XP-Clients. Ursache war eine versteckte, schreibgeschützte Datei, welche nicht kopiert werden konnte (0 Byte groß).

Im Ereignisprotokoll allerdings eine entsprechende Fehlermeldung.

Gruss, Babble.

Um was für 2003er Server handelt es sich? Bei R2 wurde das DFS-Handling gegenüber der "Nicht-R2"-Version geändert. Bisher bin ich davon ausgegangen, das es sich dabei nur um Änderungen bei DFS-R handelt. Eventuell liegt dort das Problem.

Aktuell kann ich das nicht prüfen, morgen klappts eventuell.

Gruss, Babble.

Nein.

Ein "net use x: \\domainname\FS\location01-folder01" sollte genau das gewünschte Ergebnis bringen. Gerade geprüft.

Gruss, Babble.

Upps. Weiterlesen hätte geholfen

Zum Thema DFS:

Du solltest den Namespace auf einen DC legen, der dem Standort zugeordnet ist. Die DFS-Ziele liegen auf dem Fileserver.

Namespace: \\domain.local\filer01

Ziele: \\name.filer01\Freigabe_1

Siehe auch: Grundlagen: Windows Distributed File System

oder

Sever-HowTo: Grundsätzliche Informationen rund um Microsofts DFS

Da durch DFS der Servername quasi aus der Freigabe verschwindet, sollte der Tausch eines Filers dann kein Problem mehr sein.

Gruss, Babble.

Wäre es nicht möglich, die Fileserver über einen DFS-Stamm anzusprechen? Das Ordnerziel kann ja wechseln, der Stamm-Name bleibt immer gleich.

lg, Babble.

Am einfachsten ist es, die DHCP-Daten mit netsh dhcpserver export all in eine Datei zu exportieren. Dann den alten DHCP-Dienst beenden, den Export auf dem neuen DHCP-Server importieren und dann diesen starten.

Das habe ich bereits mehrfach erfolgreich durchgeführt.

Siehe: "Netsh"-Befehle für DHCP

LG,

Babble.

Man kann das natürlich noch ausbauen. Dazu die Parameter /R:1 und /W:1 einbauen, um die Wartezeit bei geöffneten Dateien zu minimieren. Mit /XA temporäre Dateien ausklammern und mit /LOG die Logfiles mitschreiben und später sichten.

Nach der Erstspiegelung dann einen geplanten Task mit Robocopy nachts laufen lassen, um bis zum Tag X alle Daten zu migrieren. Alternativ mit /MOT: oder /MON: das alles von Robocopy erledigen lassen.

Have some fun!

LG,

Babble.

Gerne. :-)

Also ich habe solche Migrationen schön ofters mit Robocopy gelöst. Wenn du Robocopy im Backup-Modus startest (ist der Schalter /B afaik), dann sollten auch alle Daten rüberkommen:

robocopy Quelle Ziel /B /MIR /COPYALL

zum Beispiel. Dabei wird dann Quelle auf Ziel gespiegelt (löscht auch im Ziel!), die Attribute mitgenommen und das ganze im Backup-Modus.

Danach hast du eine 1:1-Kopie der Quelle.

LG,

Babble