Howard

Hallo de.le, danke für die schnelle Antwort. Funktioniert wunderbar, nochmals danke!

Hallo zusammen, kurze Frage zu den administrativen Freigaben (C$ etc.). Gibt es eine Möglichkeit, diese für lokale Admin-Konten (nicht für das lokale Administrator-Konto) zu sperren? Hintergrund ist der, das auf unseren Clients (WinXP Pro) ein zusätzliches Konto mit Adminrechten angelegt ist, damit die User Software-Installationen vornehmen können (SW-Verteilung leider noch nicht vorhanden :(). Das Problem an der Sache ist, dass die User über das LAN auch auf die administrative Freigabe anderer Rechner zugreifen können in dem sie die Benutzerkennung/PW des zusätzlichen Kontos angeben. Hat jemand eine Idee wie man diesem einem lokalen Benutzer die Rechte auf die administrative Freigabe entziehen kann? Bislang habe ich nur Mittel und Wege zum kompletten Entfernen der Freigabe gefunden... Vielen Dank schon mal....

Abschlussmeldung Es war der Fehler bei der Überarbeitung der Dyn.Distr.Group via ADSI-Edit wie im vorherigen Post beschrieben. Nun läuft alles wie es soll.

Hallo nochmal, das Logging-Level hab ich mal angepasst. Eine Sache ist mir dann noch aufgefallen als ich mir den Verteiler mit adsiedit angeschaut habe. Die Einträge msExchDynamicDLFilter und msExchQueryFilter hatten unterschiedliche Kriterien, diese habe ich nun mal angepasst. Die Testmail geht dann morgen raus und dann weiß ich hoffentlich mehr.

Hi, laut Vorschau sollten es 32 Empfänger sein, 2 davon erhalten die Mails nicht. Im Tracking-Log steht der RecipientCount interessanterweise auf 32, zählt man die tatsächlichen Recipients durch kommt man aber wieder nur auf 30...

Moin, ja, es sind immer diesselben User. Die Filterbedingungen wurden nachträglich angepasst um weitere User hinzu zufügen. Wie gesagt, in der Vorschau werden sie auch angezeigt. Mit dem Absender kann es auch nicht zusammenhängen, da die Verteilerliste häufig und von unterschiedlichsten Absendern genutzt wird. Bei anderen Verteilerlisten gibt es soweit ich weiß keine Probleme.

Guten Morgen, das Tracking Log zeigt korrekt die Empfänger an, die diese Mail auch erhalten haben. Die zusätzlichen Empfänger, die per Definition auch in diesem Verteiler sind werden nicht bei den Recipients aufgeführt. Oder welche Info wäre noch wichtig?

Hallo zusammen, wir haben ein kleines Problem mit unseren dynamischen Verteilerlisten auf unseren Exchange 2007 Server. Aufgefallen ist dadurch, das einige Kollegen sich beschwert haben, sie würden Info-Mails nicht erhalten. Wir haben daraufhin mit Hilfe der Vorschaufunktion in der Verwaltungskonsole und auch mit dem entsprechenden PowerShell-Befehl die Empfänger geprüft und festgestellt, dass die Verteilerlisten (eigentlich) korrekt und vollständig sind. Ausnahmsweise haben die User aber tatsächlich nicht versehentlich E-Mails gelöscht oder servergespeicherte Filter-Regeln angelegt, sondern die Mails haben sie tatsächlich nicht erreicht. Wir haben dann eine Testmail an die betroffenen Verteilerlisten gesendet und eine Übermittlungsbestätigung generieren lassen. Die betroffenen Kollegen tauchen nicht bei den Empfängern auf, also liefern Vorschau/PowerShell-Befehl und tatsächliche Empfänger unterschiedliche Ergebnisse. Hat jemand einen Idee wo das Problem liegen könnte bzw. wie es zu beheben ist?

Hi, ich gebe mal eine kurze Zwischenmeldung: Wir haben ein Forest mit nur einer Domäne. Eventlog -> Verzeichnisdienst: ist auf allen DCs sauber DCDIAG -> Alle Test "passed", auch der FSMOCheck Infrastructure-Master ist auf allen DCs korrekt eingetragen. Es muss was an den OUs sein, denn, erstelle ich eine neue OU, lege dort einen neuen Benutzer an kann dieser ohne Probleme kopiert werden. Ich werde mir morgen mal die anderen Geschichten anschauen... Danke auf jeden Fall für deine Bemühungen!!

Hallo nochmal. Eventlog ist sauber. Die Kopieraktion kann generell nicht durchgeführt werden, egal mit welchem der 9 DCs ich mich verbinde. Tja, ich bin mit meinem Latein am Ende...

Hm, sieht sauber aus, Dom-Admins haben Vollzugriff. Ich hab die Kopieraktion unter anderem auch als Dom-Admin ausprobiert.

Keine Schrägstriche, nur Bindestriche. Aber wie schon gesagt, es hat bislang auch funktioniert.

Alle DCs laufen unter Windows Server 2003, die Domänenfunktionsebene ist ebenfalls Windows Server 2003.

Ich habs sowohl von meinen Notebook, per RDP-Session auf beiden DCs hier am Standort und auf einem DC an einem anderem Standort probiert, immer mit dem gleichem Ergebnis.

Ich kopiere einfach mit Rechtsklick auf das zu kopierende Objekt. An den Namen der OUs kann es eigentlich nicht liegen, die AD-Struktur habe ich vor ca. 2 Jahren angelegt und seither kaum verändert (zumindest keine OUs umbenannt). Bis vor kurzem funktionierte das Kopieren auch noch.

Ausschließen kann ich garnichts.. :D Ne, ernsthaft, am Schema hab ich lange nichts mehr geändert, die letze Änderung (liegt aber schon min. 1 Jahr zurück) war die Darstellung der Benutzernamen (Nachname, Vorname). Ich bin mir sehr sicher, das sonst nichts modifiziert wurde. – Hab gerade nochwas festgestellt. Wenn ich einen Benutzer aus der Default OU "Users" kopiere funktioniert es. Nur wenn ich einen Benutzer aus einer anderen, von uns erstellten OU kopieren will schlägt es fehl...

Servus, erst beim Bestätigen. Ist im übrigen auch egal, welchen Benutzer ich kopieren möchte...

Hallo zusammen, ich habe ein Problem beim Kopieren von Benutzerobjekten im Active Directory (W2k3-Domain). Beim Versuch einen User zu kopieren schlägt der Vorgang jedesmal mit der folgenden Meldung fehl: Das Objekt 'Nachname, Vorname' konnte aufgrund folgenden Problems nicht erstellt werden: Der Namensverweis ist unzulässig. Hat jemand eine Idee? Manuell anlegen eines Objektes funktioniert ohne Probleme.

Hallo, danke erstmal für die schnellen Antworten. Servergespeicherte Regeln wären aus meiner Sicht eher kritisch. Da hätte man das Ping-Pong Problem wieder falls jemand vergisst die Regel wieder zu deaktivieren (was definitiv vorkommen würde). Bei aktivierte OOF-Nachricht erinnert Outlook immer so nett ;-) Es gibt wohl ein Tool von CI, mal gucken ob das was taugt...

Hallo zusammen, eine hoffentlich einfach zu beantwortende Frage zum Versand von OOF-Nachrichten (Exchange 2007 Enterprise). Wir haben den Versand von OOF-Nachrichten sowohl für interne als auch für externe Empfänger aktiviert. Nun gibt es "Beschwerden", das man bei aktivierter Abwesenheitsnotiz nur 1mal die Abwesenheitsnachricht erhält und sich dann "merken" muss, wann der Kollege wiederkommt (in meinen Augen eigentlich eine sinnvolle Konfiguration; Stichwort: Mail-Ping-Pong). Gibt es dennoch eine Möglichkeit die Versand-Intervalle von OOF-Nachrichten hochzusetzen, z.B. auf 1 Mail pro 24 Stunden?

Kurze Abschlussmeldung: Heute morgen wurde das Systemboard getauscht, auf diesem lag eine kleine, abgebrochene Metallklammer. Evtl. könnte das Ding irgendwie was mit den ersten Abstürzen zu tun haben (zumindest lt. HP). Dann haben wir durch die fehlerhaften Reparaturinstallationen dem Server den Rest gegeben.:rolleyes: Es geht nichts über eine vernüftigen Datensicherung und die IDR-Option...;) Nu läuft es wieder...

Hi Zahni, aktuellstes Support Pack für ProLiant ist drauf. Der Hotfix ist allerdings nicht installiert worden, ist nochmal ein versuch wert (sofern ich die ver***** Rep-Inst. irgendwie abwürgen kann....) Aber so richtig leuchtet mir nicht ein, warum der Server sich dann plötzlich entschließt permanent abzuschmieren und neu zu booten. Zu diesem Zeitpunkt hat sich an der Systemkonfig nichts verändert. Irgendwie deutet das doch eher auf ein Hardwareproblem hin... Memtest läuft im übrigens seit ca. 2 h ohne Probleme durch. Morgen wird dann erstmal das Systemboard von HP getauscht. Die waren sich nun doch nicht sicher, das es ein zwingend um ein Softwareproblem handelt.

Hallo, danke erstmal für Eure Antworten. Nachfolgend die Ergebnisse des ersten und des letzten Minidumps: Der erste Dump vom Samstag: *********************** Probably caused by : Pool_Corruption ( nt!ExDeferredFreePool+33c ) Followup: Pool_corruption --------- DRIVER_CORRUPTED_EXPOOL (c5) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is caused by drivers that have corrupted the system pool. Run the driver verifier against any new (or suspect) drivers, and if that doesn't turn up the culprit, then use gflags to enable special pool. Debugging Details: ------------------ BUGCHECK_STR: 0xC5_2 CURRENT_IRQL: 2 FAULTING_IP: nt!ExDeferredFreePool+33c fffff800`011a9eba 488908 mov qword ptr [rax],rcx CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP PROCESS_NAME: GetEngineFiles. TRAP_FRAME: fffffadf5cea7860 -- (.trap fffffadf5cea7860) NOTE: The trap frame does not contain all registers. STACK_COMMAND: kb FOLLOWUP_IP: nt!ExDeferredFreePool+33c fffff800`011a9eba 488908 mov qword ptr [rax],rcx SYMBOL_STACK_INDEX: 3 FOLLOWUP_NAME: Pool_corruption IMAGE_NAME: Pool_Corruption DEBUG_FLR_IMAGE_TIMESTAMP: 0 SYMBOL_NAME: nt!ExDeferredFreePool+33c MODULE_NAME: Pool_Corruption FAILURE_BUCKET_ID: X64_0xC5_2_nt!ExDeferredFreePool+33c BUCKET_ID: X64_0xC5_2_nt!ExDeferredFreePool+33c Followup: Pool_corruption ********************************* Und der letzte (verfügbare) Dump von gestern: ********************************* Unable to load image Ntfs.sys, Win32 error 2 *** WARNING: Unable to verify timestamp for Ntfs.sys *** ERROR: Module load completed but symbols could not be loaded for Ntfs.sys BugCheck 24, {19033d, fffffadf5d4be540, fffffadf5d4bdf50, fffffadf5c873ad1} Probably caused by : Ntfs.sys ( Ntfs+7aad1 ) Followup: MachineOwner NTFS_FILE_SYSTEM (24) If you see NtfsExceptionFilter on the stack then the 2nd and 3rd parameters are the exception record and context record. Do a .cxr on the 3rd parameter and then kb to obtain a more informative stack trace. Debugging Details: ------------------ CUSTOMER_CRASH_COUNT: 11 DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE PROCESS_NAME: System CURRENT_IRQL: 0 ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in "0x%08lx" verweist auf Speicher in "0x%08lx". Der Vorgang "%s" konnte nicht auf dem Speicher durchgef hrt werden. READ_ADDRESS: 0000000000000010 BUGCHECK_STR: 0x24 LAST_CONTROL_TRANSFER: from fffffa80006730f0 to fffffadf5c873ad1 FOLLOWUP_IP: Ntfs+7aad1 fffffadf`5c873ad1 8b4810 mov ecx,dword ptr [rax+10h] SYMBOL_STACK_INDEX: 0 FOLLOWUP_NAME: MachineOwner MODULE_NAME: Ntfs IMAGE_NAME: Ntfs.sys DEBUG_FLR_IMAGE_TIMESTAMP: 45d699c1 SYMBOL_NAME: Ntfs+7aad1 STACK_COMMAND: .cxr 0xfffffadf5d4bdf50 ; kb FAILURE_BUCKET_ID: X64_0x24_Ntfs+7aad1 BUCKET_ID: X64_0x24_Ntfs+7aad1 Followup: MachineOwner ****************************************** Zwischen diesen Dumps finden sich noch ca. 40 weitere, soweit ich das sehe wurden immer unterschiedliche Prozesse verantwortlich gemacht. Den Verifier.exe habe ich auch schon ausgeführt, damit fing das Schlamasel aber erst richtig an, der Verifier wollte einen Neustart, danach ging der Server nicht mal mehr in den abgesicherten Modus. Vor dem Verifier-Befehl fuhr das Ding wenigstens noch komplett hoch... Im Systemprotokoll finden sich nur Meldungen vom "eventlog": "Der Computer ist nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x000000c5 (0x0000000000000008, 0x0000000000000002, 0x0000000000000001, 0xfffff800011a9b28). Ein volles Abbild wurde gespeichert in: C:\WINDOWS\MEMORY.DMP. Memtest hab ich soeben noch mal angeworfen, bisher keine Fehler. Wir haben aber gestern schon mit den unterschiedlichsten RAM-Konfigurationen rumgetestet...

Hallo zusammen, wir haben aktuell ein großes Problem mit unserem Exchange-Server. Der Server ist in immer kürzeren Intervallen (Anfangs stündlich zum Schluss im minutentakt) abgestürzt. Zwar wurden unendlich viele Dumps generiert, alle weisen aber eine andere Fehlermeldung aus. Wir haben uns nach diversen Hardwaretest (mit der HP SmartStart CD) und der Installation der aktuellen Treiber (mit der HP Firmware-CD) dazu entschlossen, eine Reparaturinstallation durchzuführen. Die Reparaturinstallation startet auch korrekt mit dem kopieren der Daten, startet neu und sollte dann eigentlich in die grafischen Oberfläche kommen. Nur bevor er das tut steigt der Server aus und bootet neu. In den abgesicherten Modus komm ich noch rein, nur kann das Setup dort nicht weiter durchgeführt werden. Wenn ich die Reparaturinstallation neu anstossen möchte weißt mich Windows daraufhin, das noch eine aktuelle Installation (oder Update) ausgeführt wird. Ich kann dann lediglich diese Installation fortsetzen mit dem gleichem Ergebniss. Hat jemand eine Idee, wie ich aus der Bootschleife rauskommen (abgesehen von einer Neuinstallation) bzw. wie ich die noch aktive Reparaturinstallation abbrechen kann? Die Hardware scheint, sofern man den HP Tools Glauben schenken darf, in Ordnung zu sein. RAM, Prozi etc. wurden auch schon getauscht...

Hallo zusammen, wir haben aktuell ein großes Problem mit unserem Exchange-Server. Der Server ist in immer kürzeren Intervallen (Anfangs stündlich zum Schluss im minutentakt) abgestürzt. Zwar wurden unendlich viele Dumps generiert, alle weisen aber eine andere Fehlermeldung aus. Wir haben uns nach diversen Hardwaretest (mit der HP SmartStart CD) und der Installation der aktuellen Treiber (mit der HP Firmware-CD) dazu entschlossen, eine Reparaturinstallation durchzuführen. Die Reparaturinstallation startet auch korrekt mit dem kopieren der Daten, startet neu und sollte dann eigentlich in die grafischen Oberfläche kommen. Nur bevor er das tut steigt der Server aus und bootet neu. In den abgesicherten Modus komm ich noch rein, nur kann das Setup dort nicht weiter durchgeführt werden. Wenn ich die Reparaturinstallation neu anstossen möchte weißt mich Windows daraufhin, das noch eine aktuelle Installation (oder Update) ausgeführt wird. Ich kann dann lediglich diese Installation fortsetzen mit dem gleichem Ergebniss. Hat jemand eine Idee, wie ich aus der Bootschleife rauskommen (abgesehen von einer Neuinstallation) bzw. wie ich die noch aktive Reparaturinstallation abbrechen kann? Die Hardware scheint, sofern man den HP Tools Glauben schenken darf, in Ordnung zu sein. RAM, Prozi etc. wurden auch schon getauscht...