MS-Wing

Ein Archive Header encrypted 7zip File mit langem Passwort (30 Zeichen min.) ist ziemlich unbrauchbar für alle die das Passwort nicht haben. Momentan nicht knackbar unter 1 Millionen Jahre... In die Berechnung sind schon distributed Attacks miteinbezogen...

Anderer Vorschlag: Pack die Datei in ein passwortgeschützes Archiv (zip oder noch sicherer: 7zip) und lade die Datei auf einen öffentlichen Filehoster. Zum Beispiel: SendSpace.com Dann musst Du dem Empfänger nur noch die Download URL und das Passwort mitteilen. Schont nerven, Provider und noch vieles mehr... :D Gruß, Sascha

Nachdem wir mit "dnscmd /unenlistdirectorypartition" die "falschen" dnszonen rausgeschmissen haben, scheint nun alles gut zu werden! KCC meckert nicht mehr, keine roten oder gelben Einträge im Directory-Service Eventlog. Und jeder DC spricht nur noch mit den DCs mit denen er auch soll (Standortverknüpfungen). So macht AD wieder Spaß!

Nee, das Problem ist das wir mit dnscmd /enlistdirectoryparition eine dnspartition in einer ad-domäne enlisted haben, die aber diese Zone normalerweise über ad nicht empfangen würde. Anders gesagt: Domain1: Domain1-DNS Replicationscope Domain-Wide DC in Domain2: manuelles enlisten für Domain1-DNS Zone War definitiv ein Fehler, aber wir versuchen nun diese "fremde" DNS-Zone loszuwerden. Sie soll ganz normal über das Forwarding aufgelöst werden. Wir haben auf dem DC in Domain2 angegeben: dnscmd /unenlistdirectorypartition domaindnszones.domain1.irgendwas.local Hoffentlich verschwindet diese Zone bald auf dem DC in Domain2

Update: Wir haben in einem der problematischen Standorte noch ein Problem mit DNS entdeckt (manuell angelegte Zonenreplikation (dnscmd /enlistdirectoryparition). Wir versuchen das gerade zu ziehen und dann zu sehen, ob sich alles normalisiert. Ich denke das die Fehler hiermit zu tun haben.

Nachdem das Häckchen entfernt wurde traten auf dem 2. DC der Forest-Root-Domain folgende Events auf (im 15 Minuten Takt): Event ID 1311 und 1865 (vom NTDS KCC). Die Meldung besagt das nicht genug Standortinformationen vorhanden sind um ein Spanning-Tree herzustellen. Ich habe jedoch alle Standorte und Subnetze definiert. Hmm. scheint was komplizierteres zu werden... Event 1311 meckert DomainDNSZones an und Event 1865 eine andere Site...

Sorry, ich muss den Thread nochmal reaktivieren. Ich habe das Häkchen entfernt, aber auch nach 2 Tagen gibt es immer noch Replikationsverbindungen, die nicht den Standortverknüpfungen entsprechen. Das entfernte Häkchen hat sich mittlerweile zu allen Standorten durchrepliziert, aber keine grosse Änderung sichtbar. Was hat dies nun zu bedeuten? Muss ich ggf. automatisch erstellte Verknüpfungen manuell löschen? Ich dachte die Verbindungen werden automatisch den neuen Gegebenheiten (keine "Bridge all site links" mehr) angepasst. Grizzly999?

Ja, danke. Irgendwo in den grauen Zellen war noch was von "Bridge all site links" übrig. Aber es ist wohl doch mit der Zeit wegdiffundiert :p

Ja, das Häkchen war gesetzt weil default. Danke für den Spitzen-Tipp! Ich denke das morgen alles so sein wird, wie ich es will.

Hallo, wer kann mir folgendes Szenario erklären: Mehrere Sites in AD: Site1, Site2, Site3, Site4, Site5, Site6, Site7, Site8 5 Standortverknüpfungen: Verknüpfung 1: Site1 Site2 Verknüpfung 2: Site1 Site8 Verknüpfung 3: Site1 Site3 Site4 Site5 Site6 Verknüpfung 4: Site1 Site3 Verknüpfung 5: Site3 Site7 Die Verknüpfungen wurden nach Kriterien generiert wie verfügbare Bandbreite und IP-Konnektivität. Keine manuell aufgesetzten Verbindungen zwischen den DC's. Alles automatisch generiert. Was ich nun nicht verstehe: Wieso baut ein DC aus Site 3 eine automatische Verbindung mit einem DC aus Site 2 auf? OK, IP-technisch sehen sich diese DCs, aber laut Standortverknüpfungen sollte sowas nicht passieren. Eigentlich sollten sich in dem Fall die Replikationsverbindungen nur in Site1 und Site2 abspielen. Diese sind IP mäßig auch korrekt verbunden. Es scheint sowieso so als würden die DC's in allen Standorten versuchen mit allen möglichen DCs reden zu wollen ohne Rücksicht auf die Standortverknüpfungen. Dies sieht man in den Firewalllogs. Im grossen und ganzen ist die automatisch generierte Topologie nachvollziehbar. Aber es gibt eben DC-Verbindungen, die nicht zu den manuell festgelegten Standortverbindungen passen. Es sieht fast so also ob diese Standortverbindungen nur so eine Art "Vorschlag" and das AD sind, aber AD bei entsprechender Konnektivität diese Vorschläge ignoriert und so noch andere zusätzliche Verbindungen schaltet (als backup?). Aber kann jemand das mal genauer erklären? Gibt es eine Möglichkeit die absolut strikte Berücksichtigung der Standortverbindungen zu erzwingen (ausser manuelle DC-Verbindungen zu generieren)? mfg Sascha

OK, das ist doch mal ein Wort. Danke für die Info! Danke auch an Lemmi. Deine praktische Erfahrung klärt die Frage ziemlich eindeutig.

Irgendwelche Referenzen im Web, oder reine Mutmassung?

Das ist so nicht richtig! Der CachedLogonsCount legt fest wieviele Logons von UNTERSCHIEDLICHEN Benutzern lokal gespeichert werden und nicht wie oft man sich hintereinander anmelden darf. Habe ich gerade praktisch mit 10 reboots ohne Netzwerk ausprobiert. CachedLogonsCount stand auf 2. Ich konnte mich jedoch 10 mal hintereinander immer wieder anmelden. Bitte nächstes Mal besser recherchieren! Also zurück zur Ursprungsfrage (siehe oben). Gruß, Sascha

Hallo, wie lange bleiben eigentlich Domänen-Anmeldeinformationen im XP-Client gecached? Kann der Benutzer sich endlos oft an der Domäne anmelden, falls der DC mal für seeeeehr lange Zeit ausfällt? Was passiert wenn in dieser Zeit das Domänenkennwort abläuft? Ist die Anmeldung dann trotzdem möglich und Kennwort muss erst wieder beim nächsten DC-Kontakt geändert werden? Konnte leider nicht so richtig erquickende Antworten im Web finden. Gruß, Sascha

Messpc ist eigentlich OK. Aber wenn man wirklich eine plug-and-play Lösung (also quasi Appliance-Lösung sucht), die nicht zusätzlichen Krach verursacht, bzw. auch nicht durch monatliche WSUS-Microsoft Updates gequält wird, so ist die AKCP-Lösung vorzuziehen. Eben eine kleine Box die vollkommen PC unabhängig ist. Wenn das Budget natürlich eine Rolle spielt, dann kann ich Deine Entscheidung nachvollziehen.

Bestimmte Server haben auch mehrere Sensoren onboard. Je nachdem ob Du den entsprechenden Sensor auslesen kannst hast Du auch eine gute Messung. Zum Beispiel Sensor für die Temperatur der einfließenden Luft. Auf dem Server muss dann natürlich die entsprechende Systemmanagement-Software installiert sein, die vom Hersteller mitgeliefert wird. OK, bietet natürlich keine Lösung für die Feuchtigkeitsmessung.

AKCP Sensorprobe 2: Von Software kann man ja da nicht direkt sprechen. Eher Firmware ;) Firmwareupdates kommen ab und zu raus und sind einfach einzuspielen (über Kommandozeile/TCP-IP). Ansonsten: Funktionales Webinterface mit Historie und entsprechender Mailbenarichtigung bei bestimmten Schwellwerten. SNMP-Unterstützung mit Traps. NTP wird auch unterstützt und externer SYSLOG Server. Es wird Software mitgliefert (DataCollect) mit der man die Werte in eine Textdatei zur weiteren Verarbeitung schreiben kann. Wir nutzen jedoch die SNMP-Unterstützung und lassen die Daten in das Monitoringsystem NAGIOS fliessen. Das Gerät ist sehr günstig und lässt keine Wünsche offen. Eben install-configure-and-forget.

Habe mich auch mal mit dem Thema beschäftigt, war aber nicht bereit in teure Lösungen zu investieren. Letztendlich bin ich sehr zufrieden mit den AKCP Produkten. Wir haben 4 Geräte von den SensorProbe 2 im Einsatz und sind damit vollends glücklich. (SNMP, SMTP, Webinterface und mehr) Informationen: AKCP Rackmonitoring

Hi, hast Du die Verteilergruppe auch Mail-Enabled? Also in Active Directory Benutzer & Computer rechte Maustaste auf die Gruppe und "Exchange-Aufgaben" auswählen. Dann "Email Adresse für Gruppen einrichten". Sonst gibt das nichts mit versenden über diese Liste.

Hi, habt ihr mal unter Longhorn/Vista in der Datenträgerverwaltung Partitionen vergrößert oder verkleinert. Das funktioniert vollkommen reibungslos und ohne jedes Mucken. Sogar die Bootpartition mit swapfile etc. kann on-the-fly vergrößert oder verkleinert werden!!! Auf Zusatztools kann man also in Zukunft verzichten (z.B. Acronis Diskdirector) Bin superschwer beeindruckt! :jau:

Sorry, aber sehe irgendwie nicht den Zusammenhang zu Windows... Eher was für das Off-Topic Forum. oder einfach mal hier gucken. http://www-5.ibm.com/de/partners/bp/bp_eserv.html Immer muss man alles selber machen... :mad:

Du kannst auch SmartSniff von nirsoft.net probieren. Ein intelligenter Sniffer (ohne WINPCAP installation!!) der nach quelle, ziel und port sortiert. Coole Sache!

Hmm, schwierig. Chkdsk C: /F schon probiert? Gibt es während dieser 100% Phase verstärkten Disk-Zugriff? Irgendeinen Prozess der auf 100% CPU Auslastung steht? Vielleicht mal filemon mittracen lassen was da so passiert.

Seit wir Windows 2003 für den Fileserver einsetzten mussten wir keine einzige Datei von Band wiederherstellen und haben eine Historie die über einen Monat zurückreicht (40GB Shadowspeicher mit default Schedule-Settings bei ca. 400 GB Fileserverdaten). Das ist Luxus pur!

Wäre der Server Windows 2003 würde ich einfach nur sagen: "Schattenkopien!". Vielleicht ein Grund auf Windows 2003 upzugraden.