michelo82

Es ist Kurios...:confused: auf der Partition wo die Logdateien liegen, sind nur Dateien von Heute. Das abschneiden geht also anscheinend doch. Ab 22:00 Uhr soll mein Exchange über die Windows Sicherung das Voll-Backup machen. Es sind keine weiteren Programme zum backupen installiert. Hier das Log: Protokollname: Application Quelle: Microsoft-Windows-Backup Datum: 18.10.2012 22:00:00 Ereignis-ID: 753 Aufgabenkategorie:Keine Ebene: Informationen Schlüsselwörter: Benutzer: SYSTEM Computer: exchange Beschreibung: Der Sicherungsmoduldienst auf Blockebene wurde erfolgreich gestartet. Protokollname: Application Quelle: MSExchangeIS Datum: 18.10.2012 22:00:18 Ereignis-ID: 9606 Aufgabenkategorie:Exchange VSS Writer Ebene: Informationen Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: exchange Beschreibung: Exchange VSS Writer (Instanz 4234e8b4-a2ed-471e-8283-868aa9e13084) hat die Vorbereitungen für die Sicherung erfolgreich abgeschlossen. Protokollname: Application Quelle: ESE Datum: 18.10.2012 22:00:24 Ereignis-ID: 2005 Aufgabenkategorie:Schattenkopie Ebene: Informationen Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: exchange Beschreibung: Information Store (4488) Schattenkopieinstanz 5 wird gestartet. Dabei handelt es sich um eine vollständige Schattenkopie. Protokollname: Application Quelle: MSExchangeIS Datum: 18.10.2012 22:00:24 Ereignis-ID: 9811 Aufgabenkategorie:Exchange VSS Writer Ebene: Informationen Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: exchange Beschreibung: Exchange-VSS-Writer (Instanz 5) hat das Datenbankmodul erfolgreich für eine vollständige oder Kopiesicherung von Datenbank 'ArchivDB' vorbereitet. Protokollname: Application Quelle: ESE Datum: 18.10.2012 22:00:24 Ereignis-ID: 2001 Aufgabenkategorie:Schattenkopie Ebene: Informationen Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: exchange Beschreibung: Information Store (4488) ArchivDB: Schattenkopieinstanz 5 Fixierung wurde gestartet.

Ja richtig.

Es betrifft sämtliche DB's (auch Öffentliche Ordner)...

Ja, der Fehler kommt trotzdem: Protokollname: Application Quelle: MSExchangeIS Datum: 18.10.2012 16:14:13 Ereignis-ID: 9782 Aufgabenkategorie:Exchange VSS Writer Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: exchange Beschreibung: Exchange VSS Writer (Instanz c3318826-4573-4512-bec1-b489e66b1fd0:4) hat die Sicherung der Datenbank 'ArchivDB' mit Fehlern abgeschlossen. Die Sicherung wurde nicht erfolgreich abgeschlossen, und es wurden keine Protokolldateien für diese Datenbank abgeschnitten. Ereignis-XML: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="MSExchangeIS" /> <EventID Qualifiers="49193">9782</EventID> <Level>2</Level> <Task>41</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2012-10-18T14:14:13.000000000Z" /> <EventRecordID>9784806</EventRecordID> <Channel>Application</Channel> <Computer>exchange</Computer> <Security /> </System> <EventData> <Data>c3318826-4573-4512-bec1-b489e66b1fd0:4</Data> <Data>ArchivDB</Data> <Binary>46756C6C00</Binary> </EventData> </Event> Und zusätzlich noch: Information Store (4488) Schattenkopieinstanz 4 wurde abgebrochen.

Ja, :) habe nur noch Log's mit Datum von Heute. Also funktionierts anscheinend doch. Woher kommen dann aber die Fehler im Eventlog?

Hat leider nicht funktioniert. Der Fehler steht nach wie vor im Eventlog. Was könnte ich noch ausprobieren bzw. welche Log-Dateien wären hilfreich? EDIT: Dieses häkchen: "Datenbank kann bei einer Wiederherstellung überschrieben werden" merkt sich Exchange auch nicht. Sobald ich den Server neu starte oder die Datenbank-Einbindung aufheben ist dieser Haken verschwunden.

Danke für den Hinweis, ich probiere es aus. ;)

Hallo, und zwar mache ich via Windows-Server Sicherung eine Vollständige VSS-Sicherung meines Exchange 2010 SP1. Die Datenmengen sind recht groß und so verweigerte mir mein Backupserver (Storage Server 2003) öfters das vollständige kopieren der Sicherungs über das Netzwerk. Erst das Anpassen von HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\IRPStackSize auf den Backupserver und Exchange brachte was. Die Sicherung wird mir in der GUI erfolgreich angezeigt: Und trotz voller VSS Sicherung werden die Logs nicht abgeschnitten: EVENT # 9781505 EVENT LOG Application EVENT TYPE Error OPCODE Info SOURCE MSExchangeIS CATEGORY Exchange VSS Writer EVENT ID 9782 COMPUTERNAME EXCH01 DATE / TIME 12.10.2012 05:46:48 MESSAGE Exchange VSS Writer (Instanz 7fb2ef13-1b43-48ee-8ff9-5d4664a32024:1) hat die Sicherung der Datenbank 'ArchivDB' mit Fehlern abgeschlossen. Die Sicherung wurde nicht erfolgreich abgeschlossen, und es wurden keine Protokolldateien für diese Datenbank abgeschnitten. BINARY DATA 0000: 46 75 6C 6C 00 Kennt jemand dieses Problem?

So langsam dämmerts mir ;) ... So wird mein Beispiel-Client angezeigt: Nur bei deinem letzten Punkt ist mir was noch unklar: Der Client hatte ja aber bevor ich irgendwas genehmigt habe nur 14 Updates angezeigt. Mag sein, dass das durch meine automatische Regel zustande kam. Der Client kann die "68" Updates doch aber erst anzeigen, wenn WSUS sie heruntergeladen hat, oder nicht?

Automatische Genehmigungsregel, hab ich nur Wichtige Updates / Sicherheitsupdates. Mhhh, aber wenn ich normal (also ohne WSUS) nach Updates suche, werden auch sofort 68 Stück erkannt. Beim WSUS eben nur so viele, wie er bereits durch meine Genehmigung heruntergeladen hat. Das waren dann eben heute Mittag 14 Stück und dann kam nach und nach immer mal ein weiteres dazu...

Das wundert mich eben auch...ich habe nur die Produkte (aber inkl. aller Klassifizierungen) ausgewählt, die ich auch tatsächlich einsetze: - Developer Tools,Runtimes, and Redistributables - Exchange 2010 - MS Essentials - Office 2007, Office 2010 etc... - Silverlight - SQL Server 2005, 2008, R2, 2012 - Win7, Win8, Defender, Srv 2003 Datacenter, Srv 2003, Srv 2008R2, Srv 2008, Srv 2012, XP Aber ~44 GB ? Ja, das kenne ich bereits. Mhhh...der Client meldet sich beim WSUS und fragt diesen nach Updates... Mit träge meine ich, dass so langsam die Updates eintrudeln.

Ahhh...3.830,69MB von 43.625,95MB heruntergeladen... Da kann es wohl sein, dass nicht alles dabei ist... Ja, natürlich. Einige Updates wurden ja angefordert von meinem Client ;) Mittlerweile: 211 Update wurden nicht installiert. 14 Update wurden heruntergeladen, jedoch nicht installiert. 4 Updates wurden installiert. (hier hat der Client wahrscheinlich noch nicht die richtige Anzahl an WSUS weitergegeben) 5768 Updates sind nicht zutreffend. Danke für den Tipp...ich merke langsam auch, dass der WSUS nicht alles Ad hoc macht so wie mir das vorstelle. Er ist etwas träge. ;)

Okay...ich beschreibs nur mal an einem Client als Beispiel: Client: Windows 7, SP1 Update Suche über WSUS findet nichts... Wenn ich aber Online suche findet er 68 Updates... Meine Windows-Update Richtlinie gilt für einen eigene OU im AD in die ich alle Clients verschoben habe. So werden diese ja auch erst mal vom WSUS Server erkannt. Ja, steht auf 4:

Teil 2 des Log: 2012-10-10 11:09:38:519 856 d08 Setup Setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256" is already installed. 2012-10-10 11:09:38:519 856 d08 Setup SelfUpdate check completed. SelfUpdate is NOT required. 2012-10-10 11:09:39:086 856 d08 PT +++++++++++ PT: Synchronizing server updates +++++++++++ 2012-10-10 11:09:39:086 856 d08 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus-server/ClientWebService/client.asmx 2012-10-10 11:09:46:848 856 d08 PT +++++++++++ PT: Synchronizing extended update info +++++++++++ 2012-10-10 11:09:46:848 856 d08 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus-server/ClientWebService/client.asmx 2012-10-10 11:09:47:363 856 d08 Agent * Found 0 updates and 71 categories in search; evaluated appl. rules of 1231 out of 1760 deployed entities 2012-10-10 11:09:47:363 856 d08 Agent ********* 2012-10-10 11:09:47:363 856 d08 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates] 2012-10-10 11:09:47:363 856 d08 Agent ************* 2012-10-10 11:09:47:363 856 df0 AU >>## RESUMED ## AU: Search for updates [CallId = {CD7AE597-3E7E-4FDC-9BCA-F592B6254FA5}] 2012-10-10 11:09:47:363 856 df0 AU # 0 updates detected 2012-10-10 11:09:47:363 856 df0 AU ######### 2012-10-10 11:09:47:363 856 df0 AU ## END ## AU: Search for updates [CallId = {CD7AE597-3E7E-4FDC-9BCA-F592B6254FA5}] 2012-10-10 11:09:47:363 856 df0 AU ############# 2012-10-10 11:09:47:363 856 df0 AU Successfully wrote event for AU health state:0 2012-10-10 11:09:47:363 856 df0 AU Featured notifications is disabled. 2012-10-10 11:09:47:363 856 df0 AU AU setting next detection timeout to 2012-10-10 17:24:53 2012-10-10 11:09:47:363 856 df0 AU Setting AU scheduled install time to 2012-10-10 11:00:00 2012-10-10 11:09:47:363 856 df0 AU Successfully wrote event for AU health state:0 2012-10-10 11:09:47:363 856 df0 AU Successfully wrote event for AU health state:0 2012-10-10 11:09:52:363 856 d08 Report REPORT EVENT: {C15B704D-768B-46A9-987E-56C9A94EC6E0} 2012-10-10 11:09:47:363+0200 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Software Synchronization Windows Update Client successfully detected 0 updates. 2012-10-10 11:09:52:363 856 d08 Report REPORT EVENT: {57D15291-9C16-4EBB-9C01-3B60C5C54667} 2012-10-10 11:09:47:363+0200 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status. 2012-10-10 11:09:52:363 856 d08 Report CWERReporter finishing event handling. (00000000) Es steht am Client einfach da, dass alle Updates bereits installiert sind! Ich habe die WSUS-Server Übersicht nochmal unten angehängt. Was mache ich falsch, dass trotz 225 erlaubter Updates gerade mal 14 Stück vom Client gezogen wurden?

Hallo, und zwar verteilt mir mein WSUS-Server nicht alle Updates. Per Gruppenrichtlinie ist festgelegt, dass Update automatisch installiert werden sollen. Der Rechner ist auch im richtigen OU im AD vorhanden. Ich habe allerdings den WSUS nicht auf den Port 8530 installiert, sondern auf den Standardeinstellungen Port 80 belassen. Im WSUS-Server selber ist eine eigene Gruppe für die Client-PCs angelegt für die alle verfügbaren Update manuell genehmigt wurden. Zusätzlich gibt es eine Regel, dass Sicherheitsupdate automatisch genehmigt werden. Aktuell gibt mir WSUS - 225 anstehende Updates für einen Client aus. Beim ersten suchen nach Update wurden allerdings nur 14 Stück installiert. Hier das Log: C:\Windows\WindowsUpdate.log 2012-10-10 11:09:38:347 856 364 AU Triggering AU detection through DetectNow API 2012-10-10 11:09:38:347 856 364 AU Triggering Online detection (interactive) 2012-10-10 11:09:38:347 856 c9c AU ############# 2012-10-10 11:09:38:347 856 c9c AU ## START ## AU: Search for updates 2012-10-10 11:09:38:347 856 c9c AU ######### 2012-10-10 11:09:38:378 856 c9c AU <<## SUBMITTED ## AU: Search for updates [CallId = {CD7AE597-3E7E-4FDC-9BCA-F592B6254FA5}] 2012-10-10 11:09:38:378 856 d08 Agent ************* 2012-10-10 11:09:38:378 856 d08 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates] 2012-10-10 11:09:38:378 856 d08 Agent ********* 2012-10-10 11:09:38:378 856 d08 Agent * Online = Yes; Ignore download priority = No 2012-10-10 11:09:38:378 856 d08 Agent * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1" 2012-10-10 11:09:38:378 856 d08 Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed 2012-10-10 11:09:38:378 856 d08 Agent * Search Scope = {Machine} 2012-10-10 11:09:38:378 856 d08 Setup Checking for agent SelfUpdate 2012-10-10 11:09:38:378 856 d08 Setup Client version: Core: 7.6.7600.256 Aux: 7.6.7600.256 2012-10-10 11:09:38:378 856 d08 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab: 2012-10-10 11:09:38:378 856 d08 Misc Microsoft signed: Yes 2012-10-10 11:09:38:410 856 d08 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab: 2012-10-10 11:09:38:425 856 d08 Misc Microsoft signed: Yes 2012-10-10 11:09:38:425 856 d08 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab: 2012-10-10 11:09:38:425 856 d08 Misc Microsoft signed: Yes 2012-10-10 11:09:38:441 856 d08 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab: 2012-10-10 11:09:38:441 856 d08 Misc Microsoft signed: Yes 2012-10-10 11:09:38:456 856 d08 Setup Determining whether a new setup handler needs to be downloaded 2012-10-10 11:09:38:456 856 d08 Setup SelfUpdate handler is not found. It will be downloaded 2012-10-10 11:09:38:456 856 d08 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.6.7600.256" 2012-10-10 11:09:38:472 856 d08 Setup Setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.6.7600.256" is already installed. 2012-10-10 11:09:38:472 856 d08 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256" 2012-10-10 11:09:38:488 856 d08 Setup Setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256" is already installed. 2012-10-10 11:09:38:488 856 d08 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256" Log geteilt!

Ok. Danke...konnten es mithilfe des Sharepoints lösen ;)

Hallo, ich bekomme Faxnachrichten und eingegangen Nachrichten auf dem Anrufbeantworter von der Telefonanlage als Mail zugestellt. Als "Absender" der Mail wird von der Telefonanlage die Telefonnummer angegeben. Problem ist, dass ich nicht weiß welcher Kunde das ist, da ich den Namen benötige. Unsere Kunden werden in einer SQL Datenbank gepflegt. Gibt es eine Möglichkeit mit Exchange SQL Datenbanken abzufragen, die Mail abzuändern und die Telefonnummer in den Kundennamen aufzulösen bzw. den Namen in den Betreff hinzuzufügen?

Speziell beim Exchange 2010 ist das aber kein Problem ;)

Jop, ist DNS und auch beim Exchange eingetragen (nachträglich). Funktioniert wieder sauber...

Exchange akzeptiert die Mails anhand der "Akzeptieren Domäne" - bei dir also das @example.com. Per Transportregeln kannst du die Mails dann beliebig weiterleiten...

Bedient euch :)

1. DC lief nach der ersten Nacht und einem Reboot des 2. DC wieder! Die FSMO's konnten somit Online übertragen werden. Trotzdem war das Dateisystem des 1. DC beschädigt und er wird jetzt neu Aufgesetzt. Vielen Dank an alle. Alles wieder in Butter.

Zumindest startet der 1. DC wieder, Anmeldung als Domänenadmin ist möglich, das Attribut userAccountControl vom 1. DC-Computerobjekts wurde wieder auf den Wert "532480" korrigiert und die Exchange GUI lässt sich wieder aufrufen. DCDIAG liefert beim 1. DC: Verzeichnisserverdiagnose Anfangssetup wird ausgefhrt: Der Homese - Pastebin.com [b]und beim 2. DC:[/b] [xml] Verzeichnisserverdiagnose Anfangssetup wird ausgefhrt: Der Homese - Pastebin.com :( Ich möchte im nächsten Schritt die FSMO's Online mit ntdsutil auf den 2. DC übertragen und den 1. DC mit DCPROMO aus der Domäne nehmen. Ist es dann auch erforderlich die Metadaten zu "säubern"? Danach möchte ich den 1. DC mit gleichen Namen, sowie gleicher IP wieder aufsetzen und hochstufen. Die Frage ist nur, ob der Exchange das verträgt. Da sich wie gesagt, die GUI erst wieder starten ließ, als der 1. DC Online war. Ich weiß nicht genau warum den Exchange der 2. DC nicht ausgereicht hat, um eine Verbindung zum AD herzustellen (ich Tippe darauf, dass dem 2. DC eben die Betriebsmaster gefehlt haben).

Der Raidcontroller ist nicht beschädigt. Allerdings startet der 1. DC, wegen des unsauberen Ausschaltens mit der Meldung: \windows\system32\config\system Hab dann: c:\windows\system32\config\system c:\windows\system32\config\software c:\windows\system32\config\sam c:\windows\system32\config\security c:\windows\system32\config\default mit den gleichen Dateien aus dem Ordner RegBack ausgetauscht. Danach kam der DC zumindest bis zum CHKDSK...danach wieder: \windows\system32\config\system Sobald man das CHKDSK abbricht, bootet der Server normal und ich konnte mich anmelden. Das userAccountControl Attribut ist geändert! Vielen Dank!

Das kann ich dann von dem laufenden 2. DC aus machen :) ?