kobalt

Klar gibt es eine Sicherung, die ist aber wohl kaum der Grund für die aufgetretenen Phänomene. Und schon gar kein Grund, der Sache nicht auf den Grund zu gehen. Grundsätzlich. Mir ist auch nicht bewusst, dass BE E-Mails abfängt und sofort sichert. Ist das ein Zusatzmodul? Vielleicht müssen wir ja upgraden. :cool:

Doch, das geht mit Gruppenrichtlinien. Im Office Ressource Kit gibt es die entsprechende *.adm-Datei. Zu finden auf Gruppenrichtlinien - Übersicht, FAQ und Tutorials unter Downloads und Links --> Downloads. Diese Vorlage musst Du im Gruppenrichtlinieneditor hinzufügen. Die gesuchte Richtlinie ist dann unter Benutzerkonfiguration --> Administrative Vorlagen --> Microsoft Office Outlook 2003 --> Tools | Options ... --> Mail Format --> Signature. Dort sollten zwei zu konfigurierende Richtlinien zu finden sein: Disable signatures for new messages und Disable signatures for replies and forwards Beide Richtlinien sind zu aktivieren. Das müsste es dann eigentlich sein. Gruß kobalt

Nein, immer noch nicht. Mir ist schon klar, dass die User nicht direkt AN den Rechnern arbeiten. Aber irgendwie müssen die Dateien ja dort hin kommen, oder? Also nehme ich an, sie arbeiten AUF den Netzlaufwerken. Beschreib doch einfach mal genauer, wie ihr arbeitet. Also, wo die Daten erzeugt werden, wie sie auf die zu synchronisierenden Rechner kommen und ob Du die Batch dann auf einem oder auf beiden laufen lassen willst. Also alles, was zum Verständnis der Umgebung nötig ist.

Hallo, mir ist noch nicht ganz klar, was Du genau bezwecken willst. Möchtest Du auf beiden Rechnern den gleichen Datenbestand haben, weil die User auf beiden arbeiten? Oder soll der erste Rechner die Referenz sein und der zweite als Backup dienen? Wenn auf beiden gearbeitet wird, wie verhinderst Du, dass zeitgleich zwei Dateien mit dem gleichen Namen erzeugt werden?

Ich kann von Norman Virus Control ebenfalls nur gutes berichten. Einfache Installation und Verwaltung, relativ geringer Ressourcenverbrauch. Außerdem ist Norman extrem zuvorkommend gegenüber ihren Partnern. Keine Hotline in einem irischen Callcenter, direkte Durchwahl zur Technik, falls Du (bzw. dein Kunde) von einer kleineren Lizenz upgraden willst bezahlst Du nur die Differenz, es gibt kostenfrei Home-Lizenzen, d.h. Kunde kauft 5 Lizenzen für die Firma, dann dürfen 5 Mitarbeiter das Produkt privat auf ihren Rechnern verwenden. Ein einziges Mal gab es in den letzten zwei Jahren Schwierigkeiten bei einem Update, so dass wir ein Rollback machen mussten bis zum nächsten Patch. Das wars.

Es gibt schon ein paar Fehler im Ereignisprotokoll. Ich würde sie aber als Folge der fehlerhaften DNS-Einträge interpretieren. Der Auslöser bleibt unklar. In "Anwendung" sind ein paar Warnungen von MSExchangeMTA, dass die MTA-Datenbank wieder hergestellt worden ist. Außerdem Fehler von BackupExec. Im "DNS-Server" Fehler ID 4015 und drei mal 4004 mit der Meldung, dass im AD kritische Fehler festgestellt worden sind. in "System" Fehler 40960 Quelle LSASRV mit der Meldung, dass das Sicherheitssystem einen Authentifizierungsfehler für den Server festgestellt hat. Entsprechend gab es natürlich auch Replikationsfehler zwischen den beiden DCs. Wie gesagt, in meinen Augen alles Folgefehler.

Hallo Stoni, nein, da ist nichts zurückgespielt worden. Und ich weiß ja selbst, dass es das eigentlich nicht geben kann. Meine Äuglein waren im Moment des Erblickens so groß wie die des Smileys... Also, irgendwelche Ideen wo solche "Reste" herkommen können?

Hallo, zusätzlich zu dem hier geposteten Problem http://www.mcseboard.de/windows-forum-lan-wan-32/alter-dc-ploetzlich-dns-125522.html existiert noch ein weiteres. Bei einem Benutzer - und bis jetzt tatsächlich nur bei einem - sind von gestern auf heute alle Termine aus seinem persönlichen Kalender verschwunden. Ich habe mir die PRIV1.EDB mit MFCMapi und Ontrack PowerControls angeschaut - nichts! Weitere Auffälligkeit bei diesem Benutzer war in den letzten Tagen, dass er zwar E-Mails versenden und empfangen konnte, dass aber ein paar von INTERN an ihn verschickte Mails im Nirwana verschwunden sind. Meine erste Reaktion war, ein neues Mail-Profil zu erstellen. Hat aber nichts gebracht. Leider steht dadurch auch die OST-Datei nicht mehr für eine Prüfung zur Verfügung :rolleyes: Im Moment läuft gerade eine DB-Prüfung mit ISINTEG. Irgendwelche Ideen was hier schief läuft? Gruß kobalt

Hallo, heute hatte ich bei einem Kunden mal wieder ein Erlebnis der seltsameren Art. Vor einiger Zeit wurde dort die Domäne auf 2003 umgestellt. Ausgangslage: EX1 --> W2K, EX2K, DC (GC) DC2 --> W2K, DC (GC) Bei der Umstellung wurde dann ein neuer Server (frische HW) in die Domäne gebracht und mit W2K3 + E2K3 + DC (GC) installiert. Dann wurden die Benutzerkonten migriert, der EX1 wurde aus der Domäne entfernt, und zwar sauber. Erst EX deinst, dann runtergestuft und schließlich ganz aus der Domäne genommen. Der DC2 wurde platt gemacht und mit W2K3 installiert, dann wieder zum DC gemacht. Situation jetzt: SRV1 --> W2K3, E2K3, DC (GC) SRV2 --> W2K3, DC (GC) (alte HW) DNS ist AD integriert. Und jetzt kommts: heute war der SRV2 aus dem DNS verschwunden, statt dessen stand wieder der EX1 als DC drin mit der alten IP-Adresse (die zurzeit kein Rechner verwendet). :shock: Abgesehen von den Problemen, die das mit sich bringt - wie kann so was passieren??? Habe ich irgendwo noch Hinweise auf den alten DC, die ich von Hand entfernen muss? Wenn ja, wie und wo muss ich hingreifen? Vielen Dank für eure Hilfe, kobalt

Ja nun, da gibt es denn doch einen Unterschied... Mal vorausgesetzt, das ist lizenzrechtlich wirklich so gedacht, dann bedeutet das ja auch: In einer Umgebung mit 10 Usern und 50 Clients benötige ich nur 10 TS Cals aber 50 Office Lizenzen. Wo ist da die Logik? MS hat die geplante Pro-CPU-Lizenzierung verworfen und eine kundenfreundlichere Pro-User-Lizenzierung eingeführt und dann nicht konsequent weitergeführt? Warum?

Hallo, ich muss diesen Thread noch mal weiterführen. Zum einen haben wir gerade eine aktuelle Anfrage zu diesem Szenario und zum anderen scheint mir das nicht ganz ausgegoren. Bei Terminalservern wird die Berechtigung zum Zugriff auf Office (gilt natürlich auch für alle anderen Programme) ausschießlich über das Terminalserver-Benutzerprofil gesteuert. Es gibt also gar keine Möglichkeit, den Zugriff von einem bestimmten Gerät zu erlauben und von einem anderen zu verbieten. ERGO: Benutzer A ist der Zugriff auf Office erlaubt, egal von welchem Rechner er sich anmeldet. Benutzer B ist der Zugriff auf Office verwehrt, egal von welchem Rechner er sich anmeldet. Man stelle sich jetzt folgendes vor: es gibt einen Terminalserver und 500 Thinclients (ohne HDD, kein Windows) und 500 User. Nur der Chef des Unternehmens braucht Office, läuft aber den ganzen Tag im Betrieb rum und meldet sich mal an diesem, mal an jenem Client an und hat dann natürlich "sein" Office. Ich kann mir beim besten Willen nicht vorstellen, dass es von MS so gedacht ist, dass er dann 500 Office-Lizenzen kaufen muss. Einwände? kobalt

Hallo, die doppelte Anzahl an Lizenzen bereit zu halten, ist ein teures Vergnügen. Wir haben das bei einem Kunden mit einem Zwischenschritt gelöst, bei dem die Downtime auch sehr gering ist. Es gibt dort zwei Terminalserver, von denen aber nur einer aktiv ist. Nachts werden die Daten per robocopy synchronisiert. Fällt TS1 aus, dann werden die Lizenzen mittels eines Anrufs beim MS Clearinghouse wieder frei gegeben und der TS2 nimmt den Dienst auf. Wenn der Ausfall tagsüber im laufenden Betrieb passiert, müssen sich die Clients ab- und wieder anmelden, damit sie die Änderung (über DHCP) mitbekommen. Fertig. Natürlich sind beide TS DCs in der gleichen Domäne. Gruß kobalt

Falls das Problem noch nicht gelöst ist: - sind alle PCs in der gleichen Arbeitsgruppe? - funktioniert der Zugriff auf \\<IP-Adresse>\<Freigabe> (statt \\<Servername>\..) ?

Hallo, eine Lösung für dein akutes Problem habe ich nicht für dich. Aber vielleicht einen Tipp für die Zukunft: wir sind von PcAnywhere und VNC abgekommen, weil die Dienste einfach zu instabil waren. Besser ist der Einbau eines IPMI-Moduls, sofern bei deinem Server möglich. Kostet ab ca. 120 Euro, hat eine eigene IP-Adresse und läuft, solange noch halbwegs Strom durchs Mainboard fließt. Ab ca. 300 Euro auch mit eigener Stromversorgung. Der große Unterschied ist, dass es nicht auf einem BS aufsetzt. Du kommst z.B. auch ins BIOS, siehst die Bootsequenz und kannst einen Neustart auslösen, als würde jemand am MB den RESET-Schalter drücken. Viele Grüße, kobalt

Hallo, die Treiber findest Du hier: Symantec Backup Exec 10d (10.1.5629) - Device Driver Installer (20061015) - Includes Tape Driver Release (23) and Robotic Library Release (67) (Intel Only) Die SCSI-ID sollte bei einem Standalone-Gerät keine Rolle spielen, aber empfohlen wird ID 3: How to resolve hardware communication/detection issues with Backup Exec Aber wichtiger: bitte überprüf noch mal deine Meldungseinstellungen in der Backup Exec Verwaltungskonsole (nicht im BEUtility!). Auf der Registerkarte "Meldungen" findest Du in der linken Navigation den Punkt "Meldungskategorien konfigurieren". Es öffnet sich das Fenster "Meldungskonfiguration", dort den Punkt "Medium entfernen" anklicken und im rechten Teil schauen, ob tatsächlich "Antworten mit: Ja" drinsteht: How to configure Backup Exec to automatically respond to media alerts, including when a backup hangs at 99%, until the user responds to a tape eject prompt Gruß kobalt

Hallo, wir haben das gleiche Laufwerk bei einem Kunden im Einsatz und mit dem Auswurf keine Probleme, sofern der Job einwandfrei gelaufen ist. - Welche Treiber verwendest Du? Aktuell müssten Symantec 5.1.23.0 vom 05.10.2006 sein. - Welcher SCSI-Controller? Einziges angeschlossenes LW? - Die Terminierung stimmt? - Welche SCSI-ID? (kaum zu glauben, kann aber tatsächlich eine Ursache sein) Gruß kobalt

OK, die Erklärung ist einfach. Excel 2003 läuft nicht auf 64bit. Server wieder platt gemacht, Windows Server 2003, 32bit, installiert und siehe da: die Schaltfläche Weiter bei der Exchange-Installation ist aktiv.

Hallo, leider klappt die Umstellung nicht so reibungslos wie erhofft. Schon der Punkt 2) des schönen Plans hat nicht funktioniert. Mir war nicht bewusst, dass man mit den SB-Versionen keine Updates machen darf... und genau die haben wir bestellt und geliefert bekommen. Ergo bin ich dabei, den Server SRV02 komplett neu zu installieren. Jetzt hab ich allerdings ein echtes Problem bei der Installation vom Exchange. Die Domäne sieht im Moment so aus: SRV01 --> immer noch W2K, immer noch DC, immer noch EX 2000 SRV02 --> wird zur Zeit neu aufgesetzt SRV03 --> Win Srv 2003 Std R2, 64bit; DC + GC + Betriebsmaster FORESTPREP und DOMAINPREP sind selbstverständlich gemacht; sowohl mit der Windows- als auch mit der Exchange CD. Beim Starten der Installationsroutine vom Exchange bricht er mit der Fehlermeldung ab: Der Link ist natürlich für die Füße; alle Foreneinträge, die ich gefunden habe, sagen, ich kann die Meldung ignorieren und das Setup fortsetzen. Aber genau das kann ich eben nicht! Die Schaltfläche für Weiter ist ausgegraut. Ich bräuchte hier dringend Rat. Am Montag muss alles wieder laufen. kobalt

OK, vielen Dank für den Hinweis. Dann hätte ich einen neuen Vorschlag: auf SRV02: ADPREP /.. SRV02 mit winnt32.exe auf Windows Server 2003 R2 updaten (gemäß Yusufs Blog) den neuen Server SRV03 (2003) in die Domäne aufnehmen SRV03 zum DC machen, Replikation Exchange 2003 auf SRV03 installieren in der gleichen Organisation Postfächer umziehen auf SRV01 Exchange deinstallieren SRV01 demoten SRV01 abschalten Gut so? :p

Hallo, herzlichen Dank für die Antworten. So ganz klar ist es mir aber noch nicht. Ich möchte ja nicht beide Server austauschen. Wäre folgende Vorgehensweise nicht auch machbar: 1) SRV01 (bisher DC und Exchange) zum Memberserver herunterstufen 2) auf SRV02 (jetzt einziger DC): ADPREP /.. 3) SRV02 mit winnt32.exe auf Windows Server 2003 R2 updaten 4) den neuen Server SRV03 (2003) in die Domäne aufnehmen 5) SRV03 zum DC machen, Replikation 6) Exchange 2003 auf SRV03 installieren in der gleichen Organisation 7) Postfächer umziehen 8) SRV01 abschalten Geht das, oder hat der Exchange 2000 ein Problem, wenn die Domäne auf 2003 ist?

Hallo, bisher habe ich leider keine Entsprechung für genau mein Szenario gefunden. Welche Reihenfolge ist hier zu empfehlen: IST: SRV01 --> W2K Server, DC, Exchange 2000 SRV02 --> W2K Server, DC, FSMO-Rollen, WSUS, Fileserver, Printserver SOLL: SRV02 --> W2K3 Server, DC, FSMO-Rollen (?) SRV03 --> W2K3 Server, DC, Exchange 2003 SRV01 --> abschalten Weitere Server (auch keine Memberserver) gibt es nicht. Zusammengefasst soll also die Domäne von 2000 auf 2003 migrieren und der Exchange auf einen neuen Server mit neuer Version umziehen. Vielen Dank im Voraus, kobalt

Hallo Günther, Danke für deinen Rat. Ich habe es (fast) so gemacht. Lediglich den Exchange komplett zu deinstallieren war mir zu aufwändig. Daher habe ich lediglich einen neuen Postfachspeicher (mit neuer edb-Datei) angelegt und die PFs dorthin importiert. Anschließend habe ich den alten (nunmehr leeren) Postfachspeicher gelöscht. Die Sicherung mit BackupExec hat daraufhin tadellos funktioniert, die Transaktionslogs sind gelöscht. Das Problem sollte also gelöst sein. Gruß kobalt

Ich meine nein, aber ich prüfe es lieber noch mal nach. An was denkst Du mit deiner Empfehlung? Dauerhaftes Abschalten ist nämlich nicht möglich, es handelt sich um ein Notebook. Viele Grüße, kobalt

Hallo Christian, ist das Problem gelöst? Wir haben ein ähnliches mit W2K/Ex2K. Kürzlich hatten wir ein DB-Problem mit dem Exchange. Ich bin der Empfehlung von Guenther (Danke schön!) gefolgt und habe einen neuen Informationsspeicher angelegt. Anschiessend habe ich die Elemente aus dem defekten Postfachspeicher (auf verschiedenen Wegen) in den neuen importiert. Anschließend den alten Postfachspeicher gelöscht. Bei mindestens einem Benutzer besteht nun das oben beschriebene Problem. Die Zählung von Laufwerk M: ergibt ca. 10.330 Elemente in der edb-Datei. Im Outlook-Kalender sind aber nur ca. 10.080 Elemente enthalten (Rechtsklick auf Kalender --> Eigenschaften --> Registerkarte Synchronisierung). Das tatsächliche Fehlen von Einträgen konnten wir anhand versendeter Terminanfragen überprüfen; es ist also nicht nur ein "statistisches" Problem. Viele Grüße und vielen Dank im voraus, kobalt

Hallo Christoph, Danke für den Hinweis. - im Eventlog taucht der Fehler -1018 auf - eseutil /mh meldet für alle Datenbankdateien "Clean Shutdown", keine Logs required - eseutil /k meldet priv1.edb ohne Fehler, priv1.stm mit Seitenfehler (1 Fehler) - Integritätsprüfung der PowerControls melden priv1.edb mit 28 Prüfsummenfehlern sowie 39 defekten Objekten; entweder error 0x80004005 oder "was corrupted" - eseutil /p hinterlässt die DB völlig unbrauchbar (3x versucht) Im Moment läuft das System scheinbar problemlos. Dennoch lassen sich einige Postfächer nicht verschieben. Eine Kleinigkeit hat sich mittlerweile noch ergeben. Es gibt bei mind. einem Benutzer eine E-Mail, die sich auch im Outlook nicht löschen lässt. Fehler: "Ein Client-Vorgang ist fehlgeschlagen". Da ich den Verdacht habe, dass es an diesen Mails liegt - wie kriege ich denn nun die einzelnen Mails oder Objekte gelöscht? Wenn das nicht möglich ist, wie könnten wir sonst vorgehen, um die Postfächer in den sauberen Postfachspeicher umzuziehen? Viele Grüße, kobalt