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
Google Analyticator – Warning: stream_get_contents() SSL: fatal protocol error
Ich habe mir das Google Analyticator Plugin für WordPress installiert und bekam immer Fehlermeldungen
Warning: stream_get_contents() [function.stream-get-contents]: SSL: fatal protocol error in /var/www/....../domainname/wp-includes/http.phpon line 1024
Ich fand dann herraus, dass Google Analyticator cURL verwendet um eine Verbindung auf zubauen. Also habe ich noch das passendePHP Module (php5-curl) installiert und nun funktionierts.
Excel WM Planer zur Fussball-Weltmeisterschaft in Suedafrika
Es ist mal wieder so weit, vom 11.6. bis 11.7.2010 herrscht wieder mal Ausnahmezustand und das Thema Fussball regiert die Medien.
Vom Fussballfieber ergriffen, haben sich 3 Spezialisten in Sachen Microsoft Excel mit einer Designerin zusammengetan und das Gemeinschaftsprojekt "Excel WM Planer" gegründet um eine Excel Anwendung zur anstehenden Fussball WM zu schreiben.
Der Excel WM Planer beinhaltet alle Spiele der WM 2010 und gibt auch eine Übersicht aller Spielorte.
Hier sind nicht nur alle Spiele der WM verzeichnet, ihr könnt euch selbst beim Tippspiel versuchen und gegeneinander wetten 
Hier gehts zum Download: http://www.excel-soccer-2010.de/downloads
VMware Player 3 und Netzwerk Konfiguration
Wer schon länger den VMware Player nutzt, wird ab der Version 3.0 das Tool vmnetcfg.exe vermisst haben.
Das Tool vmnetcfg.exe ist für die Konfiguration der virtuellen Netzwerke und deren Beziehung zu den physikalischen Netzwerkkarten (NIC) notwendig. Leider wird das Tool seit VMware Player 3.0 nicht mehr mit installiert, ist aber noch im Lieferumfang enthalten und muss manuell entpackt und ins VMware Programm Verzeichnis kopiert werden.
Und das geht so:
- das Setup File entpacken
VMware-player-3.0.1-227600.exe /e .\entpackt
- dann aus der network.cab die vmnetcfg.exe ins Programm Verzeichnis kopieren (C:\Program Files (x86)\VMware\VMware Player\vmnetcfg.exe)
Und dann kann vmnetcfg.exe wie gewohnt verwendet werden.
XP Mode vs. VMware Player
Microsoft macht viel Werbung mit dem XP Mode in Windows 7, doch was ist da dran?
Vor einigen Tagen hat Microsoft-Manager Brandon LeBlanc im Windows Blog angekündigt, dass bei den Anforderungen an die Hardware nachgebessert werden wird. Bisher funktionierte der XP Mode nur, wenn der Prozessor Intels VT- oder AMDs V-Technik unterstützte.
In diesem Artikel wird der Windows 7 XP Mode mit dem VMware Player verglichen, um die Praxistauglichkeit zu testen.
XP Mode
Um den Windows 7 XP Mode installieren und betreiben zu können sind einige Vorrausetzungen nötig. Es wird ein Windows 7 Professional oder höher vorrausgesetzt. Bis zum heutigen Tag muss der Prozessor Intels VT- oder AMDs V-Technik unterstützten, damit die Installation funktioniert.
Wenn diese Vorrausetzungen erfüllt sind, kann der XP Mode runtergeladen und installiert werden. Die Installation selbst besteht aus zwei Teilen, dem Virtual PC und dem Windows XP Image (VHD). Nach der Installation ist der virtuelle XP "Rechner" einsatzbereit, es muss nur noch ein Kennwort für den User festgelegt werden und dann gehts los.
Bei der virtuellen Maschine fällt auf, dass es beim Virtual PC kein Support für 3D Grafik gibt, was ein Nachteil sein kann.
Für den Benchmark Test wurde PassMark 7.0 verwendet. Vor dem Benchmark Test sind die System auf den Patch Stand März 2010 gebracht worden. Der Benchmark Test selbst stolpert über die fehlende 3D Grafikunterstützung und lässt den zutreffenden Test aus. Die Leistung des Virtual PC mit XP Mode liegt bei 282.3 Punkten, was nicht besonders viel ist.
VMware Player
Als Vorraussetzung an das Hostsystem, stellt der VMware Player ungefähr die gleichen Anforderungen wie der Virtual PC von Microsoft. Den VMware Player kann man bei VMware.com kostenfrei runterladen.
Nach der Installation ist allerdings ein Reboot notwendig, da einige virtuelle Hardware Geräte, wie z.B. Netzwerkkarten, installiert werden. Es ist mir leider nicht gelungen die VHD vom XP Mode im VMware Player zu verwenden, da das darin enthaltene Windows XP beim Start im VMware Player eine Aktivierung erfordert, die Microsoft verweigert. VMware schreibt aber auf ihrer Webseite, dass sie mit dem XP Mode kompatibel sind:
Windows XP Mode Compatible
— Import a Windows XP Mode virtual machine using VMware Player 3.0 and run the virtual machine without being prompted to enter a Windows XP license key. VMware Player enables the Windows XP Mode virtual machine to take advantage of more than one processor, render high-end graphics, integrate seamlessly with Unity, and transfer files easily with drag and drop, and shared folders. VMware Player also has the ability to run concurrently with Windows XP Mode.
Darum wird im VMware Player ein neuer Windows XP Rechner aufgesetzt und auf den gleichen Patch Stand gebracht. In dieser VM lieft der Benchmark Test fehlerfrei durch, da der VMware Player eine virtuelle 3D Grafikkarte mitbringt und somit 3D Grafikunterstützung liefert. Das Windows XP kam im VMware Player auf 489.7 Punkte, was deutlich besser ist als der XP Mode.
Fazit
Die beiden Benchmark Ergebnisse sprechen ja schon für sich, aber es gibt einige Detail, die man bei der Wahl beachten muss.
Der XP Mode hat den Vorteil, dass keine extra Lizenz benötigt wird, da die im Produkt enthalten ist. Genau das ist auch der Grund wieso eine Windows 7 Professional oder höhere Version benötigt wird, da Microsoft nur die Business Kunden damit adressiert. Der VMware Player hingegen darf auf allen Versionen von Windows 7 installiert werden, bedarf aber einer extra Windows XP Lizenz für das XP in der VM.
Der VMware Player hat eine 3D Grafikunterstützung, die im Virtual PC leider fehlt. Beide Virtualisierungssysteme unterstützen die Funktion, die Anwendungen in einem extra Fenster darstellen zu können, ohne das die ganze VM angezeigt werden muss, bei VMware Unity genannt.
Der Test wurde auf einem IBM T60 Notebook durchgeführt, was 651 Punkte im Benchmark erreicht.
Alles in Allem ist der Einsatz solcher Virtualisierungssysteme im Businesseinsatz bei mehr als 10 Endgeräte eher unpraktisch, da der Versaltungsaufwand für die virtualisierten XP Systeme sehr groß und auch diese Systeme pflege und Updates benötigen. Da sie nicht permanent laufen und teilweise auch nicht mehr abgeschaltet werden müssen, sondern nur angehalten werden, ist die Pflege nur manuell möglich. Im Businessbereich sollte man sich eher über eine zentralisierte und managebare Lösung gedanken machen.
PowerCLI cmdlets for vCenter Update Manager
Die PowerCLI Update Manager cmdlets sind da!
Laut einem Blogeintrag im PowerCLI Blog, stellt das neue PowerShell snapin die folgenden 13 cmdlets bereit:
Cmdlet Name Cmdlet Description Attach-Baseline Attaches baselines to the specified Template, VirtualMachine, VMHost, Cluster, Datacenter, Folder, and VApp objects. Attaching a baseline to a container object such as a folder or datacenter transitively attaches the baseline to all objects in the container.
Detach-Baseline Detaches baselines from the specified inventory objects. Download-Patch Downloads new patches into the Update Manager patch repository from the enabled patch download sources. Get-Baseline Retrieves the baselines specified by the provided cmdlet parameters.
Get-Compliance Retrieve baseline compliance data for the specified object of type Template, VirtualMachine, VMHost, Cluster, Datacenter, Folder, and VApp. Get-Patch Retrieves all available patches or those specified by the provided cmdlet parameters. Get-PatchBaseline Retrieves all patch baselines or those specified by the provided cmdlet parameters. New-PatchBaseline Creates a new patch baseline. Patch baselines can be applied to either hosts or virtual machines. Depending on the patch criteria you select, patch baselines can be either dynamic or static (fixed). Remediate-Inventory Remediates an inventory object against the specified baselines. Remove-Baseline Deletes the specified baselines from their servers. Before the removal, the baselines are detached from all entities they have been attached to.
Scan-Inventory Scans inventory objects for baselines attached to them. Set-PatchBaseline Modifies the properties of a patch baseline. You can specify explicitly the patches you want to include in the baseline through the IncludePatch parameter. Stage-Patch Initializes staging of patches. Staging allows you to download patches from the Update Manager server to the ESX/ESXi hosts, without applying the patches immediately
Download und mehr Informationen sind hier zu finden: http://communities.vmware.com/
Release Notes gibt es hier: http://communities.vmware.com/docs/DOC-12075
Das online manual gibt es hier: http://www.vmware.com/
Es wird eine Installation von PowerCLI 4 update 1 benötigt, bevor die Update Manager cmdlets installiert werden.
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 |
Aus 2x 2GB RAM werden 3GB
Notebooks wurden und werden seit bestimmt gut vier Jahren mit Hardware-Architekturen gebaut und verkauft, die in den allermeisten Fällen bis zu 4 Gigabyte Arbeitsspeicher zulassen. Das wird dem Käufer zumindest erzählt. Meistens sind nur 1 GB bis 2 GB verbaut, aber aufrüstbar sind die meisten angeblich bis zu 4 GB.
Bisher reichten mir die 1 GB in meinem IBM/Lenovo T60 auch - allerdings fand ich die Verwendung von Windows 7 als 64bit-Version ganz interessant. Und da ein 64bit-OS auch mehr als 3,5 GB adressieren kann, habe ich den aktuellen Preisverfall genutzt und mir spontan 4 GB reingesteckt.
Was ich hätte bleiben lassen können. Im Bios noch als 4 GB erkannt, war mit Windows und Ubuntu Linux dann plötzlich Schluss mit lustig. 3070 MB - mehr war nicht rauszuholen.
Der Hersteller meines Geräts gibt, da habe ich mich nicht getäuscht, offiziell im Datenblatt und auch noch einmal gesondert "up to 4 GB" an. Um auf Nummer Sicher zu gehen habe ich dann auch nochmal die Hotline bemüht - Aussage: muss funktionieren, wenn nicht ist Microsoft schuld. *super*
Aufklärung brachte dann folgendes Posting in einem Forum:
"Maximum memory capacity may require the replacement of standard component with largest supported component available. On ThinkPad systems with an Intel 945GM, 945PM, GM965, or PM965 chipset, even though it is possible to physically install 4GB of memory, the actual amount of memory addressable by an operating system will be limited to 3GB. This limitation does not exist with the Intel GM965 and PM965 with the 64-bit operating systems Windows XP Professional 64-bit and Windows Vista 64-bit Editions."
Auf Deutsch: es ist abhängig vom verwendeten Chipsatz. Da meins einen aus der ersten Auflistung enthält, war der Ofen damit aus.
Das betrifft übrigens nicht nur IBM/Lenovo, sondern z.B. auch HP und sogar MacBooks, die hier ebenfalls bewusst oder unbewusst mit falschen Aussagen werben. Erst bei neueren Modellen wird auf den Missstand hingewiesen (aber erst im vorletzten Absatz des "Kleingedruckten").
Also auch bei aktuellen Modellen lieber zweimal hinschauen.
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.