27.1.2011 von dr-exchange.

Exchange Server 2010 erfordert per Default eine verschlüsselte Verbindung der MAPI-Clients. Da Outlook 2003 standardmäßig diese nicht aktiviert hat, kann damit in aller Regel nicht auf 2010-Postfächer zugegriffen werden.

 Werden nun aus welchen Gründen auch immer weiterhin vorläufig Outlook 2003-Clients zum Einsatz kommen, dann müssen Sie entweder den Clients beibringen, dass die Verbindung verschlüsselt wird, oder aber Sie schalten auf dem Client Access Server die geforderte verschlüsselte RPC-Verbindung aus.

A. Verschlüsselte Verbindung in Outlook konfigurieren
Die bevorzugte Option sollte die Verschlüsselung clientseitig aktiviert werden. Die Option befindet sich unter Extras - E-Mailkonten - Exchange Server - Weitere Einstellungen - Sicherheit . In einer größeren Umgebung kann das über einen per Gruppenrichtlinie verteilten Reg-Key erfolgen. Dieser lautet:

HKCU\Software\Policies\Microsoft\Office\11.0\Outlook\RPC  à REG_DWORD “EnableRPCEncryption” : 1

B. Exchange 2010 RCP-Encryption abschalten
Um die erzwungene Verschlüsselung auf Exchange 2010 CAS abzuschalten wird folgendes Kommando in der Exchange Management Shell abgesetzt:

“Set-RpcClientAccess –Server <Name-des-CAS> -EncryptionRequired $false”

Geschrieben in Tipps & Tricks 2010, Outlook-Client | Drucken | Keine Kommentare »

27.1.2011 von dr-exchange.

Exchange Server 2010 unterstützt prinzipiell Outlook ab der Version 2003 mit ServicePack 2. Da jedoch Outlook 2003 vollständig per MAPI also RPC-Zugriffen arbeitet, kann es sehr schnell zu Problemen bei der Verbindung mit den Postfächern auf einem Exchange Server 2010 kommen. Hintergrund ist hier eine defaultmäßige Begrenzung auf dem CAS-Server, da dieser standardmäßig maximal 20 gleichzeitige Connections vom Client aus erlaubt.

Hat man ein oder mehrere zusätzliche Postfächer eingehängt oder/und greift auf freigegebene Kalender zu ist die Grenze in der Regel schnell erreicht. Insbesondere trifft dies auch auf “spezielle” Services wie z.B. Blackberry und Archivierungslösungen zu, da diese mehrere Postfächer gleichzeitig öffnen (müssen). 

Um festzustellen, ob das Problem für einen bestimmten Benutzer zutrifft, hilft folgendes Kommando in der Exchange Management Shell. Entscheidend ist an der Ausgabe die Anzahl der Zeilen mit “Client=MSExchangeRPC” am Ende.

“Get-LogonStatistics -Identity <mailboxalias> | fl applicationid”

Abhilfe schafft die Erhöhung des folgenden Wertes. Der maximale Wert liegt hier bei üner 2 Milliarden; ich habe auch schon einen Server gesehen, der für ein und denselben User über 900 gleichzeitige Connections offen hatte.

“Get-throttlingpolicy | set-throttlingpolicy -rcamaxconcurrency 32″

Dieser Wert sollte schrittweise erhöht werden, bis es keine RPC-Zugriffsprobleme mehr bei den Clients gibt.

Hinweise:

- Starten Sie nach den Änderungen den Dienst “MSExchangeRPCClientAccess” durch
- Zu diesem Problem gibt es auch einen Microsoft KB-Artikel mit der Nummer 978777 der auf dieses Problem hinweist.

Geschrieben in Tipps & Tricks 2010, Outlook-Client | Drucken | Keine Kommentare »

17.9.2010 von dr-exchange.

Aus welchen Gründen auch immer, ist es zuweilen notwendig den Internet Information Server (IIS) neu zu installieren. Auf einem System mit installiertem Exchange Server ist das wahrlich kein einfaches Re-install, denn Exchange setzt direkt auf dem IIS auf und muss somit auch neu installiert, oder zumindest neu konfiguriert werden. In diesem Workshop spielen wir für die aktuell meist verwendeten Exchange Versionen 2003 und 2007 durch, wie in diesem Fall vorzugehen ist. In den u.a. Quellangaben finden Sie die zugehörigen Quellen, in denen dies noch ausführlicher beschrieben ist.Natürlich sollte vor allen Arbeiten eine vollständige Sicherung gemacht werden, bevor Hand angelegt wird. Hier in Stichpunkten die Vorgehensweise:

Reinstall IIS auf Exchange 2003 Server(Quelle: http://support.microsoft.com/kb/320202)

• Alle Postfachspeicher- und Öffentlichen Informationsspeicher-Datenbanken dismounten
• Alle Exchange Services stoppen
• Die MDBDATA-Verzeichnisse für alle Datenbanken umbenennen als Sicherung der aktuellen Datenbanken. Damit stehen im ungünstigsten Fall auf jeden Fall sauber geschlossene (clean shutdown) Datenbanken für einen Disaster Recovery zur Verfügung
• Über Systemsteuerung – Software – Windows-Komponenten den IIS komplett entfernen
• Den IIS mit allen notwendigen Teilkomponenten wie NNTP, SMTP, ASP neu installieren
• Den aktuellen Windows Server 2003 Servicepack sowie Hotfixes und Updates einspielen. (z.B. über WSUS fehlende Packs nachinstallieren lassen)
• Exchange Server neu installieren (Reinstall-Option)
• Exchange Servicepacks und Hotfixes wieder einspielen
• MDBDATA wieder umbenennen und somit Originaldatenbanken am Originalort wieder herstellen

Reinstall IIS auf Exchange 2003 Server Cluster
Bei einem Exchange 2003 Cluster verhält es sich naturgemäß ein wenig anders. Hier macht es in meinen Augen absolut Sinn, den “beschädigten” Cluster-Node komplett aus dem Cluster zu nehmen und vollständig neu hochzuziehen. Ich persönlich würde diese Vorgehensweise einer “Reparatur-Installation” immer vorziehen.

Reinstall IIS auf Exchange 2007(Quelle: http://support.microsoft.com/kb/320202)

• Datenbanken dismounten und Datenbankverzeichnisse umbenennen
• Exchange Dienste stoppen
• Den IIS komplett entfernen
• Den IIS mit allen notwendigen Komponenten neu installieren
• Servicepacks und Updates einspielen
• Sofern der Exchange Server die Client Access Rolle hält, muss diese nun über das Exchange Server Setup entfernt und wieder neu installiert werden.

Dies kann auch über die Kommandozeile mit “exsetup.exe /mode:uninstall /roles:ca” und “exsetup.exe /mode:install /roles:ca” erfolgen.Handelt es sich beim betroffenen Server gleichtzeitig um einen Server mit der Postfach-Rolle, müssen abschließend die Virtuellen Verzeichnisse im IIS neu angelegt werden um die Verbindung zwischen Client Access und den Postfächern wieder herzustellen.Hierzu sind in der Verwaltungsshell die entsprechenden Kommandos nacheinander auszuführen:

• get-owavirtualdirectory -server Servername -DomainController DC-Name | ? {$_.OwaVersion -eq “Exchange2003or2000″} | remove-owavirtualdirectory -DomainController DC-Name
• new-OwaVirtualDirectory -OwaVersion “Exchange2003or2000″ -VirtualDirectoryType “Mailboxes” -DomainController DC-Name
• new-OwaVirtualDirectory -OwaVersion “Exchange2003or2000″ -VirtualDirectoryType “Exadmin” -DomainController DC-Name
• new-OwaVirtualDirectory -OwaVersion “Exchange2003or2000″ -VirtualDirectoryType “PublicFolders” -DomainController DC-Name
• new-OwaVirtualDirectory -OwaVersion “Exchange2003or2000″ -VirtualDirectoryType “exchweb” -DomainController DC-Name

Hinweise

Ersetzen Sie Servername durch den Namen des Exchange 2007-Servers, sowie DC-Name durch den Namen des Domänencontrollers.

Reinstall IIS auf Exchange 2010.Für einen eventuellen Reinstall des IIS auf Exchange 2010 habe ich noch keine gültigen Aussagen gefunden bzw. gehört. Ich nehme stark an, dass dies genauso abläuft, wie beim Exchange 2007, kann dies aber offiziell noch nicht bestätigen.In einer Testumgebung hat es so funktioniert.In der Praxis würde ich wohl eher dazu neigen, das gesamte System bei einem IIS-Fehler neu aufzusetzen, zumal ich mit einer DAG (Database Availability Group) die Postfächer vorübergehend auf einen anderen Exchange Server verlagern kann.

Geschrieben in Tipps & Tricks 2010, Tipps & Tricks 2007, Tipps & Tricks 2003, Tipps & Tricks 2000 | Drucken | Keine Kommentare »

17.9.2010 von dr-exchange.

Hab gerade von Bernd Kruczek den Hinweis bekommen, dass er einen ausführlichen Artikel zum Thema Migration zu Exchange 2010 für die Computerwoche geschrieben hat. Ich hab mir diesen eben angesehen, sieht sehr gut aus –> daher ein “must read” von Dr. Exchange

Computerwocheartikel Migration Exchange Server 2010

Geschrieben in Tipps & Tricks 2010, Tipps & Tricks 2007, Tipps & Tricks 2003, Allgemein | Drucken | Keine Kommentare »

20.7.2010 von dr-exchange.

SPAMfighter Exchange Module (SEM) ist ein benutzerfreundliches Anti-Spam-Produkt für Microsoft Exchange Server 2000, 2003, 2007 und 2010 in kleineren und mittelgroßen Unternehmen.

SEM wird von über 7 Millionen SPAMfightern aus 228 Ländern unterstützt. Wenn genügend SPAMfighter die gleiche Spammail melden, wird diese sofort bei allen SPAMfighter- und SEM-Benutzern aussortiert. Das bedeutet sofortigen Spamschutz ohne Konfiguration oder Wartung. PAMfighter Antispam Modul integriert sich perfekt im Microsoft Exchange Server, erlaubt eine einfache Installation/Verwaltung und benötigt keine extra Clientsoftware. Die Your-Admin hat SEM seit einiger Zeit mit sehr zufriedenstellendem Ergebnis im Einsatz.Der Hersteller stellt uns für unsere Blog-User noch folgende kostenfreie Lizenzen zur Verfügung. Die nächsten beiden Kontakte erhalten folgende Lizenzen:

• Der 1. Maileingang:   100 User Lizenz
• Der 2. Maileingang:       5 User Lizenz

Sollten Sie an einer kostenlosen Lizenz interessiert sein, eine Mail an info(at)your-admin.com genügt. Weitere Information zum SPAMfighter: http://www.spamfighter.com/Lang_DE/Product_SEM.asp

Geschrieben in Sonstiges, Tipps & Tricks 2010, Tipps & Tricks 2007, Tipps & Tricks 2003, Tipps & Tricks 2000, Allgemein | Drucken | Keine Kommentare »

7.5.2010 von dr-exchange.

Heute ist es mir passiert, dass ich auf meinem Windows 7 64-Bit-Client die Verwaltungtools von Exchange 2010 installieren wollte. Dabei hat mich folgende Fehlermeldung angeleuchtet.

Klar, irgendwas vergessen und flott einen Reboot durchgeführt und dabei geärgert, dass ich danach wieder alle Fenster öffnen muss :). Setup erneut gestartet und schon kam die Meldung wieder. Nachdem ich mich ein paar Minuten erneut geärgert habe, dachte ich mir: “Woher weiß das Setupprogramm das?” Kann ja nur aus der Registry kommen. Und so war es, folgender Key war dafür verantwortlich - wie auch immer der da hineinkam - man beachte den Pfad nach C:\windows\temp

 HKLM\SYSTEM\CurrenControlSet\Control\Session Manager\PendingFileRenameOperations

Den Key umbenannt und die Prüfung im Setup mit “Wiederholen” neu gestartet und schon sind die Tools installiert. Es gibt da im Übrigen noch einen anderen Key namens “UpdateExeVolatile” unter HKLM\SOFTWARE\Microsoft\Updates, der dafür verantwortlich sein kann.

Geschrieben in Tipps & Tricks 2010, Sonstiges, Allgemein | Drucken | Keine Kommentare »

14.4.2010 von dr-exchange.

Microsoft hat im aktuellen Security Bulletin eine Reihe von Sicherheitspatches veröffentlicht:

• Security Update for Exchange 2000 Server (KB976703)
• Security Update for Exchange Server 2003 Service Pack 2 (KB976702)
• Update Rollup 10 for Exchange Server 2007 Service Pack 1 (KB981407)
• Update Rollup 4 for Exchange Server 2007 Service Pack 2 (KB981383)
• Update Rollup 3 for Exchange Server 2010 (KB981401)

Geschrieben in Sonstiges, Tipps & Tricks 2010, Tipps & Tricks 2007, Tipps & Tricks 2003, Tipps & Tricks 2000, Allgemein | Drucken | Keine Kommentare »

1.4.2010 von dr-exchange.

Im Zusammenhang mit mailbox-moves stellen sich eine Menge Fragen, insbesondere auch was die Nutzung der entsprechenden Tools der verschiedenen Exchange Versionen für diesen Zweck betrifft. Hier nun eine kleine Zusammenstellung - welche ich aus dem Blog (How Exchange Works) übernommen habe - der Punkte, die dabei zu beachten sind:

Exchange 2003 –> 2010

• Es muss das cmdlet “move request” aus der Exchange 2010 Shell verwendet werden
• Exchange 2003 System Manager kann NICHT genutzt werden
• Der Move findet offline statt, d.h. der User kann nicht arbeiten während des Moves.
• Kein Move von Exchange 2003 SP1 oder früher möglich, erst ab SP2 aufwärts

Exchange 2007 –> 2010

• 2010 Console oder cmdlets können verwendet werden
• “Move-mailbox” cmdlet aus der 2007 Shell kann nicht verwendet werden
• Der Mailbox move ist online, der User kann also während des Movens arbeiten
• Kein Move von Exchange 2007 SP1 oder früher möglich

Exchange 2010 –> 2003

• Es muss das cmdlet “move request” aus der Exchange 2010 Shell verwendet werden.
• Exchange 2003 System Manager kann NICHT genutzt werden
• Der Move findet offline statt, d.h. der User kann nicht arbeiten während des Moves.
• Falls die Mailbox auf 2010 eine Archiv-Mailbox angehängt hat, sollte diese zuvor deaktiviert werden.

Exchange 2010 –> 2007

• Es muss das cmdlet “move request” aus der Exchange 2010 Shell verwendet werden.
• “Move-mailbox” cmdlet aus Exchange 2007 shell kann nicht verwendet werden.
• Der Move findet offline statt, d.h. der User kann nicht arbeiten während des Moves.
• Kein Move zu Exchange 2007 SP1 oder früher möglich
• Falls die Mailbox auf 2010 eine Archiv-Mailbox angehängt hat, sollte diese zuvor deaktiviert werden.

Ergo:
Man sollte stets die Tools aus Exchange 2010 verwenden, dann ist man auf der sicheren Seite!

Geschrieben in Tipps & Tricks 2010, Tipps & Tricks 2007, Tipps & Tricks 2003, Tipps & Tricks, Allgemein | Drucken | Keine Kommentare »

13.1.2010 von dr-exchange.

Postfachdatenbanken und die darin enthaltenen Daten sind für jede Exchange-Organisation äußerst wichtig. Um die hohe Verfügbarkeit von Postfachdatenbanken zu gewährleisten, bot Exchange 2007 verschiedene Replikations- und Clusterbildungsoptionen, darunter fortlaufende lokale Replikation, Einzelkopiecluster und Postfachclusterserver.

Exchange Server 2010 zeichnet sich durch einen völlig anderen Ansatz zur Erreichung hoher Verfügbarkeit aus, weil hohe Verfügbarkeit bereits in die Kernarchitektur integriert wurde. Daraus ergibt sich eine Komplettlösung, die Dienstverfügbarkeit, Datenverfügbarkeit und automatische Wiederherstellung bietet. Ergebnis ist, dass eine zentrale Hochverfügbarkeitslösung die vielen verschiedenen Lösungen ersetzt, die zuvor verwendet wurden. Diese Lösung heißt Database Availability Group (DAG).

Quelle: Technet-Magazin Hochverfügbarkeit unter Exchange Server 2010

Geschrieben in Tipps & Tricks 2010, Tipps & Tricks, Allgemein | Drucken | Keine Kommentare »

5.10.2009 von dr-exchange.

Die Hoffung, dass jeder Exchange Administrator seine Umgebung vorschriftsmäßig sichert, bleibt in aller Regel erfüllt. Zu wichtig sind die Daten der E-Mailpostfächer für ein Unternehmen. In diesem Workshop stellen wir uns aber mal eine andere Situation vor, nämlich dass zwar die Exchange Datenbanken sauber und erfolgreich gesichert worden sind, aber - aus welchen Gründen auch immer – die Situation eintritt, dass das Active Directory mit allen Benutzerkonten „verloren“ ging. Das kann nicht sein sagen Sie? Oh doch, auch das durfte ich in meiner langjährigen Tätigkeit tatsächlich schon mehrfach erleben, - leider.

Wie auch immer, dieser Beitrag zeigt auf, wie man aus einer Postfachdatenbank eines Exchange Server 2003 die zu den Postfächern gehörenden Benutzerkonten restaurieren kann, um nicht alle Konten von Hand neu anlegen zu müssen. Sicher wären die folgenden Schritte auch ein Weg für eine Umgebung mit wenigen Benutzern/Postfächern.

• Active Directory neu aufsetzen und Konten neu anlegen
• Exchange Server neu installieren
• Postfachspeicher-Datenbank aus Sicherung einspielen
• Jedes Postfach mit einem Benutzerkonto wiederverbinden

Gehen wir nun aber mal davon aus, dass wir die Benutzerkonten nicht alle kennen und uns die viele Handarbeit schenken wollen. Exchange 2003 speichert zu den Postfächern auch Daten über die zugeordneten Benutzerkonten aus dem AD. Diese Tatsache machen wir uns in diesem Workshop zu Nutze.

Microsoft Support bietet dazu ein Tool, welches bis Exchange 2000 auch auf der CD unter Support\Tools mitgeliefert wurde: Mbconn.exe. Leider wird das Tool nicht mehr mit Exchange 2003 ausgeliefert, obwohl es auch in dieser Version prima funktioniert. Sie können das Tool direkt downloaden:

ftp://ftp.microsoft.com/PSS/Tools/Exchange%20Support%20Tools/MBConn/

Der erste Schritt für die erfolgreiche Wiederherstellung der verwaisten Postfächer ist nun die Postfachdatenbank aus der Datensicherung zurück zu holen und an einem neuen Exchange Server bereit zu stellen.

Hinweis:
Eine Exchange Server Datenbank kann jederzeit an einem anderen Exchange Server bereit gestellt werden, sofern der Name der Organisation und der administrativen Gruppe identisch sind. Sollten Sie nicht oder nicht mehr wissen, wie die genaue Bezeichnung der Exchange Organisation und der entsprechenden administrativen Gruppe war, können Sie das mit dem nachfolgenden Befehl direkt aus der Datenbank extrahieren.

D:\Exchange\MDBData> find “/ou=” priv2.edb

Nun erhalten Sie eine lange Liste der LegacyExchangeDN, aus der Sie eindeutig den Org- und Admingroup-Namen erkennen können. (z.B.)

/o=YOUR-ADMIN/ou=Erste administrative Gruppe/cn=Recipients/cn=Hans.Meier

Mit diesen Angaben können wir nun problemlos im neuen Active Directory eine neue Exchange Organisation sowie Exchange Server installieren, die den Namen entsprechen, die für die zurück zu sichernde Postfach-Datenbank entscheidend sind. Abschließend zeigt  ein Blick mit dem System Manager unter Postfachspeicher – Postfächer – alle Postfächer dieser Datenbank an, natürlich versehen mit dem „roten Kreuz“ für „abgehängtes“ Postfach. (Bild 1)

Diese Daten der abgehängten Benutzer in dem betreffenden Postfachspeicher machen wir uns nun mit Hilfe des Tools „Mbconn.exe“ zu Nutze. Dazu starten wir das Tool und verbinden uns im ersten Dialog mit dem betroffenen Exchange Server und einem erreichbaren Globalen Katalog. (Bild 2)

Im nächsten Schritt wird der betreffende Postfachspeicher ausgewählt: (Bild 3)

Das Tool listet nun alle abgehängten Postfächer dieses Stores auf (Bild 4).  

Über den Menüpunkt ACTIONS – EXPORT USERS erstellen wir im nächsten Schritt eine LDF-Datei, mit dessen Hilfe wir die benötigten Benutzerkonten per LDIFDE im Active Directory anlegen lassen. Dabei muss zwingend eine OU des Active Directories als Ziel für die zu erzeugenden Benutzerkonten angegeben werden. (Bild 5)

Durck Klick auf die Schaltfläche „Generate“ wird im angegebenen Verzeichnis eine LDF-Datei erzeugt, deren Inhalt per Editor bei Bedarf auch noch nachbearbeitet werden kann.

dn: CN=Lindermeier\, Robert,OU=Benutzer,DC=Your-Admin,DC=intern
changetype: add
UserAccountControl: 66048
msExchUserAccountControl: 0
displayName: Lindermeier, Robert
objectclass: user
samAccountName: RLINDERMEIER

Die zuvor angelegte LDF-Datei wird nun als Vorlage für den Benutzerimport verwendet. Der nachfolgende Befehl erzeugt daraufhin in der angegebenen OU die benötigten Konten.

C:\Temp> ldifde -i -f c:\temp\Users-to-recreate.ldf

Hinweis:
Sollte folgender Fehler auftreten:

Fehler in Zeile 1: Ausführung verweigert
Serverseitiger Fehler: “1325″

• Löschen Sie bei dem Benutzerkonto die Zeile UserAccountControl: xxxxx.

Der abschließende Schritt ist nun, die verwaisten Postfächer mit den neu erzeugten Benutzerkonten zu verbinden. Dazu kann das Tool Mbconn.exe verwendet werden. Im Tool Mailbox Reconnect klicken wir im Menü ACTIONS – PREVIEW ALL um für alle Postfächer das zugeordnete Konto zu finden. (Bild 6)

Alle Konten werden nun den Postfächern zugeordnet und im Active Directory wieder verbunden. Dazu wählen wir das Kommando ACTIONS – APPLY. (Bild 7)

Eine abschließende Meldung gibt Aufschluss über den Erfolg der Aktion. Natürlich könnte man auch die Postfächer über den Exchange System Manager einzeln zuordnen, aber das Tool macht die Angelegenheit natürlich einfacher, vor Allem lassen sich damit in einem Zug eine ganze Liste an Postfächern wieder verbinden.

Anmerkung:
Das Tool kann sowohl in Exchange 2000 als auch Exchange 2003 Umgebungen verwendet werden, jedoch nicht mehr unter 2007. Diesen Vorgang beschreibe ich in einem der folgenden Beiträge.

Geschrieben in Sonstiges, Tipps & Tricks 2003, Tipps & Tricks 2000, Allgemein | Drucken | Keine Kommentare »