Error – move Mailbox from Exchange 2003 to Exchange 2010
Bei einer Migration von einer Exchange 2003 Umgebung auf Exchange 2010 bin ich auf ein ungewöhnlichen Fehler gestoßen. Als die ersten Mailboxen von Exchange 2003 auf die neue Exchange 2010 Umgebung verschoben wurden, kam es bei einigen Mailboxen zu Fehlern wie folgendes Log zeigt:
Log Name: Application Source: MSExchange Mailbox Replication Date: 17.6.2011. 11:29:28 Event ID: 1110 Task Category: Request Level: Warning Keywords: Classic User: N/A Computer: ExDB01.testing.local Description: The Microsoft Exchange Mailbox Replication service was unable to apply search criteria to a search folder. The error was ignored. Request: Primary (48706c9c-ad51-40d6-98b1-eb11039385e5) Folder name:/To-Do-Search Error: MapiExceptionInvalidEntryId: Unable to SetSearchCriteria. (hr=0x80040107, ec=-2147221241) Diagnostic context: Lid: 26926 Lid: 22830 StoreEc: 0x80040107 Lid: 32558 Lid: 18222 StoreEc: 0x80040107 Lid: 26414 Lid: 19246 StoreEc: 0x80040107 Lid: 18094 Lid: 27310 StoreEc: 0x80040107 Lid: 32382 Lid: 31358 StoreEc: 0x80040107 Lid: 16510 Lid: 31358 StoreEc: 0x80040107 Lid: 16510 Lid: 31358 StoreEc: 0x80040107 Lid: 26750 Lid: 22654 StoreEc: 0x80040107 Lid: 22161 Lid: 19089 StoreEc: 0x80040107 Lid: 18065 Lid: 26257 StoreEc: 0x80040107 Context: -------- Operation: IDestinationFolder.SetSearchCriteria OperationSide: Target Primary (48706c9c-ad51-40d6-98b1-eb11039385e5) Restriction: Restriction: AND[AND[PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000001A268000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010A00000005B10002000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000007DC6E000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000001A266000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCA000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCB000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCC000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DC9000000000000000000000000]]]; AND[EXIST[ptag:237764866]; BITMASK[ptag:MessageFlags, EqualToZero, mask:0xC]]] EntryIDs: [[len=46, data=0000000020EAD2782070D3118CB000105AF14FD70100712D5DEA935BD3118CA900105AF14FD700000001A2620000]] Flags: Restart, Recursive, NonContentIndexed, FailOnForeignEID -------- Search folder: '/To-Do-Search', entryId [len=46, data=0000000020EAD2782070D3118CB000105AF14FD701008A7E0BD32E921449A8B66F31569AEBF10000002E58E60000], parentId [len=46, data=0000000020EAD2782070D3118CB000105AF14FD70100712D5DEA935BD3118CA900105AF14FD700000001A2610000] Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="MSExchange Mailbox Replication" /> <EventID Qualifiers="32772">1110</EventID> <Level>3</Level> <Task>2</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2010-09-23T09:29:28.000000000Z" /> <EventRecordID>55259</EventRecordID> <Channel>Application</Channel> <Computer>ExDB01.testing.local</Computer> <Security /> </System> <EventData> <Data>Primary (48706c9c-ad51-40d6-98b1-eb11039385e5)</Data> <Data>/To-Do-Search</Data> <Data>MapiExceptionInvalidEntryId: Unable to SetSearchCriteria. (hr=0x80040107, ec=-2147221241) Diagnostic context: Lid: 26926 Lid: 22830 StoreEc: 0x80040107 Lid: 32558 Lid: 18222 StoreEc: 0x80040107 Lid: 26414 Lid: 19246 StoreEc: 0x80040107 Lid: 18094 Lid: 27310 StoreEc: 0x80040107 Lid: 32382 Lid: 31358 StoreEc: 0x80040107 Lid: 16510 Lid: 31358 StoreEc: 0x80040107 Lid: 16510 Lid: 31358 StoreEc: 0x80040107 Lid: 26750 Lid: 22654 StoreEc: 0x80040107 Lid: 22161 Lid: 19089 StoreEc: 0x80040107 Lid: 18065 Lid: 26257 StoreEc: 0x80040107</Data> <Data>-------- Operation: IDestinationFolder.SetSearchCriteria OperationSide: Target Primary (48706c9c-ad51-40d6-98b1-eb11039385e5) Restriction: Restriction: AND[AND[PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000001A268000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010A00000005B10002000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000007DC6E000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000001A266000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCA000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCB000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCC000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DC9000000000000000000000000]]]; AND[EXIST[ptag:237764866]; BITMASK[ptag:MessageFlags, EqualToZero, mask:0xC]]] EntryIDs: [[len=46, data=0000000020EAD2782070D3118CB000105AF14FD70100712D5DEA935BD3118CA900105AF14FD700000001A2620000]] Flags: Restart, Recursive, NonContentIndexed, FailOnForeignEID -------- Search folder: '/To-Do-Search', entryId [len=46, data=0000000020EAD2782070D3118CB000105AF14FD701008A7E0BD32E921449A8B66F31569AEBF10000002E58E60000], parentId [len=46, data=0000000020EAD2782070D3118CB000105AF14FD70100712D5DEA935BD3118CA900105AF14FD700000001A2610000]</Data> </EventData> </Event>
Als ersten Schritt wurde dem "move request" die Option "Skip the corrupted messages" mit dem Wert von 5 mitgegeben. In der Regel waren im Durchschnitt nur 3 korrupte Objekte betroffen. Dadurch wurden die Mailboxen erfolgreich übertragen.
Bei näherer Untersuchung stellte ich fest, dass der Fehler nur bei Nutzern auftritt, die ihr Outlook im "Cache Mode" betreiben und die Aufgabenliste (To-Do Bar) verwenden. Wenn der "Cache Mode" bei den betroffenen Nutzern in den Outlook Optionen abgeschalten wird, ist die Aufgabenliste leer bzw. wird nicht angezeigt. Wenn der "move-Mailbox" Prozess bei 10% abbricht, so handelt es sich bei den korrupten Objekten um Standard Ordner oder Such-Ordner, wie in diesem Fall beschrieben. Sollte der Prozess bei einer höheren Prozentzahl abbrechen, so handelt es sich um individuelle korrupte Objekte.
Das Problem kann auf zwei Arten gelöst werden, entweder mit Outlook Commandline-Switches oder mit dem Tool "MFCMAPI".
Die Outlook Variantre:
Bei den meisten Nutzern reichte es aus Outlook mit folgenden "Switches" zu starten, um die korrupten Objekte zu bereinigen:
outlook.exe /cleanfinders
Bei einige Nutzern reichte das leide nicht aus um alle korrupten Objekte zu bereinigen, dazu wurde Outlook dann mit folgenden "Switches" aufgerufen:
outlook.exe /cleanreminders /resettodobar
Damit wurden nahe zu alle Mailboxen bereinigt und konnten dann problemlos verschoben werden. Bei den ganz hartnäckigen Fällen half dann nur noch "MFCMAPI".
Die MFCMAPI Variante:
Bei den hartnäckigen Fällen verbindet man sich mit MFCMAPI und löscht den “Reminders” oder “Tracked Mail Processing” Ordner (kein permanente Löschung vornehmen!). Danach konnten alle Nutzer verschoben werden, ohne dass weitere korrupte Objekte gemeldet wurden.
Sollte es darüber hinaus weitere Probleme mit fehlenden Aufgabenbereichen (To-Do Bar) geben, dann öffnet man die Mailbox mit MFCMAPI und löscht (permanent/unrecoverable) den Ordner "To-Do Search" aus dem Root der Mailbox.
Links:
http://www.msxfaq.de/tools/mfcmapi.htm
Druckertreiber Isolation unter Windows Server 2008 R2
Mit Windows Server 2008 R2 gibt es endlich Änderungen bzgl. der Druckerverwaltung. Es ist nun möglich, einzelne oder alle Druckertreiber in verschiedenen Modi arbeiten zu lassen. Dieses nennt sich “Printer Driver Isolation” bzw. auf Deutsch “Treiberisolation“.
Damit es es nun endlich möglich, Druckertreiber in eigenen Prozessen laufen zu lassen. Dies hat den riesen Vorteil, dass fehlerhafte Treiber den Spooldienst eines Printservers nicht negativ beinflußt bzw. zum Absturz bringt. Folgende 4 Modi sind einstellbar
- Kein (None)
- Freigegeben (Shared)
- Isoliert (Isolated)
- Systemstandard (Kein)
Die enzelnen Modi haben folgende Funktion:
Kein (None) / Systemstandard:
Dies ist die bisher verwendete Einstellung, wie sie z.b. auf einem Windows Server 2003 vorhanden ist. Der Druckertreiber läuft immer im Kontext des Spoolers.
Freigegeben (Shared):
Im sogenannten Freigegebenen Modus (Shared) laufen die Druckertreiber unabhängig vom Spool-Prozess in einem eigenen Task. Die Druckertreiber teilen sich einen Host Prozess.
Isoliert (Isolated):
Dies ist der neue Modus unter Windows Server 2008 R2. Dabei werden die Druckertreiber in unterschiedlichen Prozessen ausgeführt. Diese Einstellung sollte immer dann verwendet werden, wenn es Probleme mit dem Druckertreiber gibt.
Ich habe es die letzten Tage bereits eingesetzt und getestet und bin sehr positiv überrascht. Der Spoolerdienst läuft wesentlich “runder” als vorher, ein Schritt in die richtige Richtung.
Quelle: www.windows-faq.de
disable Mailbox Script
In vielen Unternehmen wird das Usermanagement von der Unternehmenssoftware (z.B. SAP) zum Teil automatisiert übernommen. Dabei werden die Daten der Mitarbeiter aus der Personalabteilung über die Unternehmenssoftware in das Active Directory eingetragen. Dafür gibt es unter anderem den Identity Manager von Microsoft, was aber nicht jetzt Thema sein soll. Beim Ausscheiden von Mitarbeitern tun sich da unter Umständen aber ein paar Lücken auf die man eigentlich vermeiden will.
In einigen Unternehmen gibt es die Policy, dass die Useraccounts nach dem Ausscheiden deaktiviert aufbewahrt werden und erst nach einer bestimmten Frist (z.B. 90 Tage) gelöscht werden. Wenn ein Useraccount deaktiviert wurde, hat der Mitarbeiter eigentlich kein Zugriff auf Daten und Dienste mehr.
Wenn wir uns in der Situation einmal nur auf Exchange und die User Mailbox konzentrieren, müssen wir leider feststellen, dass die Aussage nicht ganz zutrifft. Der Mitarbeiter hat in der Tat nach seinem Ausscheiden mit deaktiviertem Useraccount kein direkten Zugriff mehr auf seine Mails, aber seine Mailbox existiert weiterhin und stellt den gesamten Funktionsumfang bereit. Hat der Mitarbeiter vor seinem Ausscheiden eine Weiterleitung an eine externe Mailadresse eingerichtet, so erhält er nach dem Ausscheiden auch weiterhin jede interne Mail an seine externe Adresse.
Wie kann das vermieden werden?
Ich haben seit einiger Zeit ein Script im Einsatz, welches alle Mailboxen trennt, dessen Mitarbeiter ausgeschieden sind. Aus der Unternehmenssoftware (z.B. SAP) heraus wird der Account des Mitarbeiters deaktiviert wenn dessen Vertragsverhältnis endet. An jeden 1. des Monats läuft das Script durch und überprüft alle Accounts nach diesen deaktivierten Mitarbeitern. Dazu ist in der Abfrage von "get-qaduser" die zu durchsuchende OU vorgegeben und es werden alle Resource Mailbox (Räume und Geräte) heraus gefiltert. Dieser Filter kann mit der Variable $filter in Zeile 36 beliebig angepasst werden. Bei den zurückgegebenen Accounts wird dann noch geprüft, welcher Account eine Mailbox hat. Dazu habe ich den Wert im Feld "SamAccountName" verwendet und an "get-user" übergeben. Das Ergebnis wird dann dazu verwendet, um mit "disable-mailbox" die Mailbox zu trennen.
Systemvoraussetzungen
Für den Einsatz dieses Scriptes ist die PowerShell und das entsprechende Exchange Management PowerShell Snapin der Serverversion von Nöten. Darüber hinaus wird die Quest ActiveRoles Management Shell for Active Directory 1.3 oder höher benötigt. Dieses Snapin ist noch aus älteren Zeiten, als es noch kein Active Directory Support für die PowerShell von Microsoft gab. Wer eine Domain auf Windows Server 2008 R2 betreibt kann auch das Active Directory Snapin von Microsoft verwenden. Und nicht vergessen, es müssen auch die entsprechenden Rechte vorhanden sein, um eine Mailbox trennen zu können.
Das Script sieht dann so aus:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 | ############################################################## # # # Script to disable all Mailboxes of disabled Useraccounts # # # # Nico Wieczorek 02.02.2009 # # # ############################################################## #First, findout if Exchange Management Shell is loaded: $snapins = Get-PSSnapin |select name $snapincount = 0; $found = $false do { $founDName = $snapins[$snapincount].name switch ($founDName) { "Microsoft.Exchange.Management.PowerShell.Admin" {$found = $True; break} "Quest.ActiveRoles.ADManagement" {$found = $True; break} #Exchange Shell already loaded } $snapincount ++ } while ($snapincount -lt $snapins.Count) $date = ( get-date ).ToString('dd-MM-yyyy') $file = New-Item -type file "E:\Exchange\Scripts\output\$date-DisabledMailbox.csv" -force if ($found -ne $True) { Add-PSSnapin "Microsoft.Exchange.Management.PowerShell.Admin" Add-PSSnapin "Quest.ActiveRoles.ADManagement" } $AllUsers = @() $filter = "(!(|(mailnickname=confroom*)(mailnickname=car*)(mailnickname=handy*)(mailnickname=beamer*)))" $ou = "berlin.testing.local/Accounts" foreach ($objItem in Get-QADUser -Disabled -SearchRoot $ou -LdapFilter $filter) { foreach ($User in Get-User -Identity $objItem.SamAccountName -OrganizationalUnit $ou | where {$_.RecipientType -eq "UserMailbox"}) { $Datenbank = Get-Mailbox -Identity $User.Name Disable-Mailbox -Identity $User.DistinguishedName -confirm:$false $ReturnedObj = New-Object PSObject $ReturnedObj | Add-Member NoteProperty -Name "Nutzer" -Value $User $ReturnedObj | Add-Member NoteProperty -Name "Datenbank" -Value $Datenbank.Database $ReturnedObj | Add-Member NoteProperty -Name "Ablaufdatum" -Value $objItem.AccountExpires $AllUsers += $ReturnedObj } } $AllUsers function sendmail([string] $body) { $SmtpClient = new-object system.net.mail.smtpClient $MailMessage = New-Object system.net.mail.mailmessage $SmtpClient.Host = "mail.testing.local" $mailmessage.from = "exchange@testing.local" $mailmessage.To.add("support@testing.local") $mailmessage.Subject = "Disabled Mailbox Report" $mailmessage.Body = $body $MailMessage.IsBodyHtml = $TRUE $smtpclient.Send($mailmessage) } $AllUsers |export-csv $file -NoTypeInformation $body = "Disabled Mailbox report for $date <br><br><br> folgende Mailboxen wurden deaktiviert: " $bodydetail = $AllUsers |sort-object "Nutzer" |convertto-html $body = $body + $bodydetail sendmail $body |
Windows Updates mittels WuInstall automatisieren
Die Aktualisierung von Windows und Microsoft Software stellt so manchen Administrator vor einige Herrausforderungen z.B. nach der Betriebssysteminstallation das System in einem Rutsch auf den aktuellen Stand zu bringen. Da verspricht das Tool WuInstall der Firma hs²n abhilfe zu schaffen.
Warum WuInstall?
Das Aktualisieren von Windows-Systemen gehört zu den Routineaufgaben eines Administrators, üblicherweise erledigt durch automatisierte Updates mit oder ohne WSUS. Für den User bedeutet die Aktualisierung des Betriebssystems nicht nur am Microsoft Patch Day Verzögerungen: der langwierige Prozess durch sukzessives Abfragen der Windows Updates und oftmals erforderlichen Neustarts stört während der Arbeit. „Unsere Fragestellung war daher: wie kann man den gesamten Update-Ablauf benutzerfreundlicher machen. Mit WuInstall haben wir ein kleinen Tool entwickelt, das diese Anforderungen erfüllt“, so Ing. Markus Huber, Entwickler von WuInstall.
Was ist WuInstall genau?
WuInstall ist ein Kommandozeilen-Tool, mit dem ein Administrator (oder auch ein User) Windows-Updates für eine Workstation kontrolliert über die Kommandozeile durchführen kann, ohne dafür das Windows-GUI benutzen zu müssen. Es ist also ideal für automatisierte Updates oder für User, die das automatische Windows-Update ausgeschaltet haben.
Die Funktionalität ist grob vergleichbar mit dem „apt-get update/upgrade“ Befehl in Linux, für den es bisher kein Windows-Äquivalent gab. WuInstall nutzt die Windows-Update API und sucht auf dem Microsoft-Update Server bzw. auf dem internen WSUS-Server (je nach Systemkonfiguration) nach den momentan verfügbaren Updates für eine Workstation, läd diese herunter bzw. installiert sie bei Bedarf. Der Zeitpunkt wann nach Updates gesucht wird und wann diese installiert werden, kann frei festgelegt werden. Zum Beispiel lässt sich WuInstall beim Login- oder Shutdown Script einbinden, um danach mit einem sicheren PC ungestört arbeiten zu können. WuInstall wird außerdem eingesetzt, um neu aufgesetzte PCs initial auf den neuesten Patch-Stand zu bringen.
Wie sieht das in der Praxis aus?
Wie anfangs schon erwähnt, ist es eine Herrausforderung ein System nach der Installation möglichst in einem Rutsch mit allen nötigen Patches auszustatten und alles automatisiert natürlich. Ich gehe davon aus, dass in Unternehmen heut zu Tage ein Softwareverteilunssystem für die Installation und Pflege von Betriebssystem und Software eingesetzt wird (z.B. System Center Configuration Manager von Microsoft oder Empirum von Matrix42).
Bisher habe ich nach dem Installationsprozess des Betriebssystems erst den WSUS-Client mittels eines kleinen Scripts zum Update seines Kataloges gezwungen.
ForceWSUSUpdate.cmd
====================================================
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | @echo off Echo Erzwingen von automatischen Updates : Echo 1. Stoppen des Automatic Updates Service (wuauserv) net stop wuauserv Echo 2. Löschen des LastWaitTimeout registry key REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v LastWaitTimeout /f Echo 3. Löschen des DetectionStartTime registry key REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v DetectionStartTime /f Echo 4. Löschen des NextDetectionTime registry key Reg Delete "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v NextDetectionTime /f Echo 5. Neustart des Updates Service net start wuauserv Echo 6. Erkennung erzwingen wuauclt /detectnow Echo Der Client prüft nun ob neue Updates vorliegen. |
Quelle: Admin-Tipps.de
Und danach musste ein eigenes VBScript ausgeführt werden, was die GUI Interaktion simuliert und den WSUS-Client dazu bringt alle anstehenden Updates zu installieren. Es kam aber immer wieder vor, dass es Probleme mit dem Windows Script Host gab, weil Nutzer ihn abgeschalten haben oder installierte Anwendungen ihn manipulieren. Leider funktioniert dieses VBScript auch nicht mehr unter Windows 7, was mich auf die Suche nach einer neuen Lösung brachte.
Eher durch Zufall bin ich auf das Tool WuInstall von hs²n gestoßen und erkannte recht schnell das große Potenzial dieses kleinen Kommandozeilen-Tools.
Der einfache Aufruf
WuInstall /install /autoaccepteula
sorgt durch "/install" dafür, dass der WSUS-Client nach neuen Updates sucht, sie herunterläd und dann installiert, sollte ein Update eine EULA Bestätigung verlangen wird mit "/autoaccepteula" diese automatisch ohne Nutzerinteraktion bestätigt. Weitere Switches sind im HowTo von WuInstall dokumentiert. Damit können durch dieses Tool die alten Skripte endlich abgelöst werden.
Lizensierung
Das Tool WuInstall ist in zwei Versionen verfügbar. WuInstall 1.2. PRO ist kostenpflichtig, mit einer Lizenz ist man autorisiert das Tool auf 5 Servern und 50 Workstations zu verwenden, im nicht-kommerziellen Bereich (für öffentliche Institutionen) ist die Anzahl unlimitiert. Die vereinfachte Version 1.1. liegt als Freeware vor.
Feature-Umfang WuInstall 1.2. PRO
Der Hauptvorteil von WuInstall 1.2. PRO gegenüber der Freeware Version ist, dass man Updates filtern kann und entscheiden welche Updates installiert werden sollen, zum Beispiel abhängig von den Severity Levels (critical, important, moderate, low) oder der Klassifizierung (critical updates, updates, update rollups, security updates, service packs, feature packs). Ein weiteres praktisches Feature ist die Suche innerhalb der Updates, zum Beispiel nach Produktnamen. Der Installationsfortschritt lässt sich anzeigen. Der gesamte Prozess kann in Logfiles mitprotokolliert werden. Es besteht die Möglichkeit den WSUS Server zu umgehen, um beispielsweise nach der Verfügbarkeit von einem bestimmten Patch, der noch nicht auf den WSUS Server heruntergeladen wurde, zu suchen. Das automatische bestätigen von EULAs bleibt auch der PRO Version vorbehalten.
Also kurz susammen gefasst, ist das Tool WuInstall eine echte Arbeitshilfe und sein Einsatz ist vielseitig. Ich habe in meinem Praxisbeispiel gezeigt, dass der Einsatz beim Betriebssystem Rollout zum Sicherheits- und Komforgewinn werden kann. Man ist so in der Lage in kürzester Zeit ein System durchgepatched an den Kunden auszuliefern.
alle Mailboxen weg, was tun?
Man stelle sich vor, von einer Minute zur anderen sind alle Postfächer nicht mehr vorhanden. Das klingt nach dem Supergau, aber es muss nicht immer so schlimm sein, wie es auf den ersten Blick aussieht.
Es kann sein, dass durch ein Bedienfehler oder falsches Skript alle Mailboxen deaktiviert oder getrennt werden, aber in der Datenbank noch vorhanden sind. Leider sind in größeren Umgebungen die Mailboxen anfangs (noch) nicht als deaktiviert sichtbar und man fängt an zu glauben, dass die Mailboxen ganz verloren sind. Das ist bei Exchange aber relativ unwarscheinlich, viel realistischer ist die Warscheinlichkeit, dass die Datenbanktransaktion noch nicht vollständig gelaufen ist. Dabei kann es vorkommen, dass nicht alle Mailboxen als getrennt (disconnect) gekennzeichnet werden. Dies kann mittels dem Cmdlet 'Clean-MailboxDatabase' erzwungen werden. Danach sind alle getrennten Mailboxen in der Datenbank auffindbar und man kann sie wieder verbinden.
Sollten durch irgend einen Fehler alle Mailboxen getrennt werden, so kann man mit folgenden Befehlen den Feierabend retten:
Get-MailboxDatabase | Clean-MailboxDatabase $getback = Get-MailboxStatistics -Server <ServerName> | where { $_.DisconnectDate -ne $null } Enable-Mailbox -Identity $getback.DisplayName -Database $getback.Database
eBook – Understanding Microsoft Virtualization Solutions
Microsoft hat schon letztes Jahr das eBook "Understanding Microsoft Virtualization Solutions - From Desktop to the Datacenter" kostenfrei zur Verfügung gestellt. Da man nur mit Login daran kommt, hier nochmal zum Download.
Exchange Log Analyser
Das Microsoft Exchange Team hat in seinem gleichnamigen Blog ein guten Artikel über den ExLogAnalyzer veröffentlicht. Der ExLogAnalyzer ist ein Tool zur Analyse von verschiedene Logfiles (z.B.: Message Tracking Logs) von Exchange 2007 und Exchange 2010, mit dem Auswertungen über Mails und Verbindungen angefertigt werden können, um einmal zu bewerten wie der Emailverkehr eigentlich wirklich aussieht.
Ein Beispiel für die Mailgröße sieht dann so aus:
