Suchen eines speziellen Öffentlichen Ordners

Hallo zusammen, 

mit folgendem Befehl ist es möglich einen speziellen öffentlichen Ordner bzw. dessen Pfad zu lokalisieren: 

Get-PublicFolder -recurse -resultsize unlimited | where {$_.name –like "Test*"} | fl 

 Viele Grüße, Jens

Erweiterte Ausgabe von Exchange Statistiken

Hallo zusammen,

wir hatten letzte Woche die Anforderung einige Statistiken aus dem Exchange herauszuholen, die ich im Folgenden gerne weitergeben möchte.

Export aller Mailboxen auf dem Exchange Server in die Datei C:\userstats.csv inkl. dem Vor- und Nachname und der Postfachgröße in MB

Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select-Object @{Name="UserPrincipalName"; Expression={(Get-User $_.Identity.MailboxExchangeLegacyDn).UserPrincipalName}},@{Name="FirstName"; Expression={(Get-User $_.Identity.MailboxExchangeLegacyDn).FirstName}},@{Name="LastName"; Expression={(Get-User $_.Identity.MailboxExchangeLegacyDn).LastName}}, @{Name="TotalItemSize" ; Expression={$_.TotalItemSize.Value.ToMB()}} | Sort-Object -Property TotalItemSize -Descending | Export-CSV –Encoding ‘Unicode’ “c:\userstats.csv” –notype

Export aller Mailboxen inkl. ALLER Email Adressen die diesem Postfach zugeordnet sind. 

Get-Mailbox -ResultSize unlimited | select DisplayNAme, @{Name="EmailAddresses";Expression={$_.EmailAddresses}} |export-csv -path "C:\EmailAdresses.csv"

Export aller Verteilerlisten inkl. der Email Adresse der jeweiligen Verteilerliste und die Email Adressen / Namen der Mitglieder der Verteilerlisten

write-output “” > C:\outputDGmembers.txt

get-distributiongroup | Sort -Property DisplayName | foreach {

$name = $_.displayname

$Email = $_.WindowsEmailAddress

$output = ‘Group Name: ‘ + $Name + $Email

$output = ‘Email: ‘ + $Email

write-output $output >> C:\outputDGmembers.txt

Get-DistributionGroupMember $name | Sort -Property DisplayName | Select DisplayName, Alias, PrimarySmtpAddress >> C:\outputDGmembers.txt

write-output “” “” >> C:\outputDGmembers.txt

}

Mit diesem Befehl haben wir uns alle Postfachberechtigungen pro Postfach anzeigen lassen.

$a = get-mailbox 
$a |Get-Mailboxpermission | where { ($_.IsInherited -eq $false) -and -not ($_.User -like “ NT AUTHORITY\SELF”) -and -not ($_.User -like '*Discovery Management*') } | Select Identity, user, AccessRights | fl 

Ausgabe der Postfachgröße pro Datenbank

Mit dem folgenden Exchange Powershell Befehl ist es möglich pro Datenbank die Mailbox Größe sortiert nach dieser in MB auszugeben:

Get-MailboxStatistics -Database "%sernam e%\First Storage Group\mailbox database" | Sort-Object TotalItemSize -Descending | ft DisplayName,@{label="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}},ItemCount

%servername% muss durch den jeweiligen lokalen Exchange Server ausgetauscht werden

Site Affinität unter Exchange 2007

Hallo zusammen,

in größeren Umgebungen kann es vorkommen, dass Server bzw. Exchange Server in anderen AD Sites hinterlegt sind, als die Clients. Mit dem Exchange PowerShell Befehl

set-clientaccessserver -identity "CAS-Servername" -AutoDiscoverSiteScope "AD-site"

kann ein spezieller Exchange 2007 CAS Server in entsprechenden Site zuordnen, aber warum ist das überhaupt notwendig?!?
Nehmen wir an, wir haben einen Exchange Standort A mit 5.000 Benutzer und einen Exchange Standort B mit 200 Benutzern. Alle Clients aus Standort A dürfen, auch wenn es mehrere AD-Sites dort gibt, niemals auf den CAS in Standort B zugreifen und umgekehrt. Mit dem oben genannten Befehl haben wir somit Standort B bzw. den dazugehörigen CAS Server entsprechend betankt.

Parallel haben wir uns dazu die CAS Server in Standort A angeschaut und haben festgestellt, dass eben diese in einer AD-Site liegen, in der niemals Clients vorhanden sind, da eben die Clients in anderen AD-Sites im gleichen Standort hinterlegt sind.
Da stellte sich natürlich ad hoc die Frage, wie kann das Konstrukt überhaupt funktionieren, denn wenn die Clients eh schon die ganze Zeit (wir hatten vor kurzem erst den CAS Server im Standort B installiert inkl. dem o.g. PowerShell Befehl) in eimer anderen AD-Site hinterlegt sind müssten sie doch jetzt eigentlich auch auf die AD-Site zugreifen in der der neue Exchange 2007 Server (Standort B) hinterlegt ist.

So und eben genau das machen die Clients am Standort A nicht, sie greifen immer auf die korrekten CAS Server zu. Der Grund ist der, dass die Clients immer primär hinsichtlich der Site Affinität auf den zuerst installierten CAS Server zugreifen und eben dieser CAS Server ist dem Standort A zugewiesen (AD-Site mäßig).

Sodele jetzt könnte es allerdings sein, dass Microsoft eben genau diesen Zugriff mit einem zukünftigen Service Pack umwandelt, so dass wir die CAS Server dahingehend angepasst haben, dass sie keiner Site zugeordnet sind:

set-clientaccessserver -identity "CAS-Servername" -AutoDiscoverSiteScope $Null

Somit gehen wir zukünftigen Problemen proaktiv aus dem Weg.

Viele Grüße, Jens

automatisches Setzen von Verzeichnisberechtigungen für öffentliche Ordner

Hallo zusammen,

wir hatten kürzlich die Anforderung Verzeichnisberechtigugnen für öffentliche Ordner zu setzten. Da der Endbenutzer seine öffentliche Ordnerstruktur gerade am Neuausrichten war, kam eine manuelle Änderung der Verzeichnisberechtigungen auf Zuruf somit nicht in Frage. Denn sonst hätten wir jedes Mal wenn er einen neuen öffentlichen Ordner anlegt mit den Verzeichnisberechtigungen bestücken müssen.

Also haben wir das per PowerShell gelöst und als geplante Aufgabe implementiert, guckst du hier:

$PFMailEnabled_Ordnername = Get-MailPublicFolder | Get-PublicFolder | where-object { $_.ParentPath -like "\Contoso\Finance*" } | Select-Object Identity

$PFMailEnabled_Ordnername | Get-MailPublicFolder | add-adpermission -User Contoso\PF_Admin -AccessRights GenericAll

Viele Grüße, Jens

Konvertierung freigegebenes Postfach

Hallo zusammen,

Wir hatten in der Vergangenheit ein "Problem" mit s.g. freigegebenen Postfächern in einer Migrationsumgebung von Exchange 2003 nach Exchange 2007. Ein s.g. freigegebenes Postach kann in Exchange 2007 nicht via Outlook berechtigt werden. Sollte beispielsweise mein Postfach vom Typ her ein "freigegebenes Postfach" sein, könnte Herr Müller mich nicht auf seinem Postfach berechtigen. Allerdings gibt es hier schon wieder eine Einschränkung, denn mit Outlook 2003 können Berechtigungen vergeben werden, ab Outlook 2007 geht das dann nicht mehr, dann wird vor dem Namen welcher über die Adressliste ausgewählt wird ein kleines Verbotsschild angezeigt.

Begriffsdefinition:

Definition eines freigegebenen Postfachs (siehe Technet):
Zusätzlich zu den standardmäßigen Benutzerpostfächern können Sie in Exchange 2007 freigegebene und Ressourcenpostfächer erstellen. Ein freigegebenes Postfach ist ein Postfach, an dem sich mehrere Benutzer anmelden können. Ein Ressourcenpostfach ist ein Postfach, das einen Ressourcentyp darstellt, z. B. einen Konferenzraum oder eine Videoausrüstung. Ressourcenpostfächer weisen in Active Directory zusätzliche Eigenschaften auf, die Benutzer- und freigegebene Postfächer nicht haben, z. B. Kapazität.

In Exchange 2003 und Exchange 2000 gibt es keine Ressourcenpostfächer. Stattdessen müssen Sie zum Abbilden von Ressourcen freigegebene Postfächer verwenden. Wenn Sie ein freigegebenes Postfach aus Exchange 2003 oder Exchange 2000 nach Exchange 2007 verschieben, erstellt das Cmdlet Move-Mailbox das Postfach als freigegebenes Exchange 2007-Postfach. Nach dem Verschieben des Postfachs nach Exchange 2007 können Sie es in ein Ressourcenpostfach ändern. Weitere Informationen zum Ändern eines freigegebenen Postfachs in ein Ressourcenpostfach finden Sie unter Konvertieren eines Postfachs.
guckst du: http://technet.microsoft.com/de-de/library/bb124797(EXCHG.80).aspx


Ursachen:
Folgende Tätigkeit wurde wohl unter Exchange 2003 gemacht, so dass wir nun knapp 2000 s.g. freigegebenen Postfächer haben:

1. Melden Sie sich am Exchange-Server mit Domain-Administrationsrechten an.
2. Klicken Sie auf Start Programme Microsoft Exchange Active Directory Benutzer- und Computer.
3. Wählen Sie in der Baumstruktur den Benutzer aus, dessen Postfach freigegeben werden soll.
4. Klicken Sie mit der rechten Maustaste auf den Ordner und wählen Eigenschaften.
5. Navigieren Sie zur Karteikarte Exchange Erweitert und klicken auf die Schaltfläche Postfachberechtigungen.
6. Klicken Sie auf Hinzufügen und wählen den Benutzer aus, der Zugriff auf das Postfach erhalten soll und vergeben die entsprechende Rechte (z.B. Vollständiger Postfachzugriff) für den individuellen Zugriff oder mit Gruppen wie Jeder für den globalen Zugriff auf dieses Postfach.

guckst du: http://www.planet-outlook.de/exchangepostfach.htm


Lösung:
Die Lösung ist auf den ersten Blick recht logisch, es müsste lediglich der Postfach-Typ von "sharedMailbox" in "regular" umgewandelt werden, das könnte beispielsweise so aussehen: Set-Mailbox -identity "Jens Kleinhans" -type regular
Interessant wird das ganze nun, wenn nun mehrere hunderte oder tausende solcher freigegebenen Postfächer migrationsbedingt vorhanden sind. Hierzu habe ich ein kleines PowerShell Script erstellt, welches eine .csv Datei einliest und gleichzeitig die Änderungen durchführt. Eines sollte allerdings beachtet werden, es gibt sicherlich migrierte "Postfächer" die zurecht als Typ freigegebene Postfächer sein, z.B. Räume. Diese sollten somit in Ressourcenpostfächer umgewandelt werden.
In meinem Szenario mit mehreren hunderten von freigegebenen Postfächern wollte und konnte ich das somit nicht von Hand machen und so musste ich folgenden Weg einschlagen:

Export sämlticher freigegebenen Postfächer, die betroffen sind (in diesem Beispiel habe ich erstmal einige wenige selektiert,da ich nicht alles auf einmal ändern wollte (dazu fehlt mir der Mut). Im folgenden Befehl gebe ich noch eine zusätzliche Spalte namens "changeit", hier wird entweder mit "ja" oder "nein" hinterlegt ob eben diese Ziele in ein "regular" Postfach verändert werden soll, oder nicht),

get-mailbox -resultsize unlimited | where{$_.recipientTypeDetails -eq "sharedmailbox"}|where{$_.primarysmtpaddress -like "*subdomain.domain.de"}|select samaccountname,primarysmtpaddress,changeit|export-csv c:\liste.csv -notypeinformation -encoding unicode

Im nächsten Schritt habe ich die Datei "liste.csv" entsprechend angepasst, so dass in der Spalte "changeIT" "ja" oder "nein" hinterlegt ist. Wichtig ist, dass die .csv Datei wieder als CSV Datei gespeichert wird und vor allem dass die Spalten mit Komma´s getrennt sind (nicht mit Tabstop).

Nach einigen manuellen Tests habe ich dann folgenden Befehl ausgeführt:

Import-Csv -Path C:\Temp\liste.csv | Where-Object { $_.ChangeIT -eq "ja" } | ForEach-Object { Set-Mailbox -Identity $_.PrimarySmtpAddress -Type Regular }

Mit dem folgenden Befehl habe ich dann verifiziert: Get-Mailbox "Jens Kleinhans" | fl rec*

Viele Grüße, Jens

Probleme Migration der öffentlichen Ordner

Hallo zusammen,

in einem Kunden Szenario hatten wir neulich das Problem, dass die Migration der öffentlichen Ordner mittels "Re-Homing" nicht vollständig funktioniert hatte. Es wurden ca. 90% der öffentlichen Ordner auf den neuen Exchange 2007 Server übertragen, aber eine nicht unerheblich Anzahl an Öffentlichen Ordnern wurde nicht verschoben.

vom Troubleshooting haben haben wir zuerst folgende Artikkel bzw. Hotfixe eingespielt:
http://support.microsoft.com/?id=936000
http://support.microsoft.com/?id=959239

Das folgende Script hatte dann schlussendlich die Lösung gebracht, auch wenn es einige Zeit in Anspruch genommen hatte bis wir damit durchwaren, guckst du hier:

Fixing Public Folder Replication Errors From Exchange 2003 to Exchange 2007 or 2010
http://blogs.technet.com/b/bill_long/archive/2010/04/22/fixing-public-folder-replication-errors-from-exchange-2003-to-exchange-2007-or-2010.aspx

Für den Skript wird folgende benötigt:

• eine Maschine mit Outlook 2007 oder 2010
• Windows Powershell installiert
• Ein MAPI Profil , das auf alle öffentlichen Ordnern Rechte hat, die wir bereinigen wollen (am einfachsten also Rechte auf allen Ordnern)
• Ordnern, die bereinigt werden, müssen wieder ein Replikat an dem Exchange 2003 Quellserver haben. D.h. die Ordnern, die noch in den öffentlichen Ordner Instanzen auf Exchange 2003 auftauchen, müssen temporär wieder ein Replikat am alten Server haben.
  
  Dies könnte mit einem Exchange Management Shell Befehl ungefähr folgendermaßen erreicht werden, angenommen dass wir die Liste der Instanzen in der Datei filename.csv haben:
  
  Import-Csv filename.csv foreach { Invoke-Expression $('Set-PublicFolder \"' + $_.FolderPath + '" -Replicas $OldPubDB,$NewPubDB ') }

In diesem Sinne viel Erfolg bei der Migration.

Viele Grüße, Jens

Probleme mit Abwesenheitsassistenten in einer Migration

Hallo zusammen,

wir haben heute ein seltsames Problem behoben, so dass es sich lohnt darüber zu berichten. In einer Migrationsumgebung von Exchange 2003 nach Exchange 20xx kam es teilweise vor, dass einige Benutzer Probleme mit den Abwesenheitsassisten hatten. Genauer gesagt, hatte die Benutzer den Abwenseitsassistent aktiviert, es wurden jedoch blöderweise keine Abwesenheitsnachrichten versendet (weder intern noch extern).

Laut Microsoft passiert das unregelmäßig/regelmäßig bei diversen Kunden in einer Migrationsumgebung, als Workaround funktioniert das nochmalige Verschieben das Postfachs auf eine andere Datenbank.

Weiterhin wird ein Benutzer niemals seine Abwesenheitsnachrichten aktivieren kann, wenn Windows Benutzer nicht mit dem Oultook Benutzer übereinstimmt, d.h. bin ich als Jens Kleinhans im Windows/AD angemeldet und binde mir das Postfach vom Admin Jens Kleinhans ein, werde ich keine Abwesenheit aktivieren können, es sei denn ich melde mich im Windows auch als Admin Jens Kleinhans an.

Update: Microsoft hat hierzu ein Hotfix veröffentlicht, guckst du hier http://support.microsoft.com/default.aspx?scid=kb;EN-US;954574

Viele Grüße, Jens

Grenzen von Verteilerlisten

Hallo zusammen,

auch Verteilerlisten in Exchange bzw. in öffentlichen Ordnern scheinen Grenzen zu haben, was wir in der letzten Zeit haben bemerken müssen.
Das Limit von Elementen bzw. von Kontakten innerhalb von einer Verteilerliste (in unserem Fall Exchange 2007 in Verbindung mit einem Active Direcotry 2003 native) beträgt zwischen 120-130 Einträgen, was zumindest teilweise hier beschrieben ist: http://support.microsoft.com/kb/238569/EN-US/

Benutzer, die diese Verteilerliste nutzen möchten, erhalten daraufhin reht irreführende Fehlermeldungen, dass der Arbeitsspeicher nicht ausreichend sei.
Als Workaround bleibt nur die Möglichkeit die Verteilerliste zu unterteilen und/oder könnte es auch sein, dass ein oder mehrere Einträge in der Verteilerliste korrupt sind. In diesem Falle müsste eben dieser korrupte Einträge lokalisiert und behoben werden - dann klappts auch wieder mit der Verteilerliste.

Viele Grüße, Jens

Verteilerlisten erscheinen nicht in GAL

Hallo zusammen,

wir hatten in einer Exchange 2003/2007 Migration das Phänomen, dass teilweise dynamische Verteilerlisten nicht angezeigt werden (im Outlook). Die Verteilerliste an sich sah in der Exchange 2007 Management Console ganz normal aus, so dass wir zuerst den Fehler gar nicht finden konnten.

Das Problem war, dass eben geanu diese Verteilerliste unter Exchange 2003 erstellt worden ist und somit einen LADP Filter verwendet, ab Exchange 2007 werden jedoch s.g. OPATH Filter verwendet. Mit folgendem Befehl haben wir die Verteilerlist nach Exchange 2007 "migriert", so dass diese im Anschluss sofort in der GAL sichtbar war:


Set-DynamicDistributionGroup "Verteilerliste" -RecipientFilter ( .\ConvertFrom-LdapFilter (Get-DynamicDistributionGroup "Verteilerlsite").LdapRecipientFilter )

Das Script "convertFrom-LdapFilter" ist hier zu finden: http://msexchangeteam.com/archive/2007/03/12/436983.aspx

Die .ps1 Datei muss in folgenden Pfad abgespeichert werden, wo auch der o.g. PowerShell Befehl ausgeführt werden muss:
C:\Program Files\Microsoft\Exchange Server\Scripts

Viele Grüße, Jens

Move-Mailbox Script für Exchange 2003/2007 Migration

Hallo zusammen,

wir hatten im aktuellen Projekt eine Anforderung, haufenweise (weit mehr als 10.000 Benutzer) von Exchange 2003 nach Exchange 2007 zu verschieben. Genauer gesagt durften die Benutzer erst abends verschoben werden um den normalen Geschäftsbetrieb nicht zu beeinträchtigen.
Da wir hier wahrscheinlich extrem viel Zeit gebraucht hätten, haben wir uns ein PowerShell Scritp geschrieben, welches gleich mehrere Dinge auf einmal abdeckt:

• Verschieben alle Postfächer einer bestimmten Datenbank
• Verschieben alle Benutzer der bestimmten Datenbank, die sich seit Datum X nicht mehr angemeldet haben

Das hat zum Vorteil, dass wir tagsüber extrem viel Postfächer verschieben konnten, da eben nur die Postfächer einer bestimmten Datenbank verschoben worden sind, deren Benutzer seit dem Datum X nicht mehr am Exchange angemeldet waren. Da wir diese Info nur mittels WMI Abfrage von Exchange 2003 auslesen können ist das Script in diesem Fall etwas länger geworden:

$arr = @() ; Get-WmiObject -ComputerName %EX2003ServerName% -Namespace ROOT\MicrosoftExchangeV2 -Class Exchange_Mailbox Where-Object { $_.StoreName -eq "EX2003DatenbankName" -and $_.LastLogonTime -lt "20100813" } % { $arr += $_.MailboxDisplayName } ; $arr get-mailbox Move-Mailbox -TargetDatabase "EX2007Servername\Ex2007SGName\EX2007Datenbankname" -MaxThreads 12 -IgnorePolicyMatch -confirm:$false

Viele Grüße, Jens

Outlook Anywhere Test Szenario

Hallo zusammen,

es gibt für die gängigen Client Betriebssysteme den unten stehenden Registry Key mit dem es möglich ist, dass Outlook (2007) dazu gezwungen wird über http(s) sich mit dem Exchange Server zu verbinden. Im LAN verbindet sich das Outlook i.d.R "nur" mittels MAPI mit dem Exchange Mailboxserver, so dass ein Test nur erschwert möglich wäre. Mit dem unten stehenden Registry Key wird zwingend festgesetzt, dass Outlook sich nur mittels http(s) mit den Exchange Server verbinden soll.
Anders ausgedrückt ist das auch eine prima Möglichkeit um Qualität zu sichern/überprüfen:

HKCU\Software\Microsoft\Office\12.0\Outlook\RPC
neuen DWORD "DisableRpcTcpFallbackValue" Wert: 1

Der "RPC" Schlüssel ist per default nicht vorhanden, so dass dieser zuerst erstellt werden muss um danach im zweiten Schritt den DWORD zu erstellen.

Viele Grüße, Jens

OWA Passwort Änderung in Exchange 2003/2007 Transition Phase

Hallo zusammen,

wir wollten gestern in unserem Testszenario im OWA leider vergebens unser Passswort ändern, was defacto leider so nicht (mehr) funktioniert.
Aber erstmal von vorne, unser Szenario:

diverse Exchange 2003 SP2 mit sämtlichen Mailboxen
divers Exchange 2007 jeweils mit unterschiedlichen Rollen auf unterschiedlichen Servern
diverse ISA 2004 Server in der DMZ

Alle Benutzer inkl. die Testbenutzer liegen (noch) auf Exchange 2003 und greifen via RPC over https auf ihre Exchange Postfächer zu. Als wir nun die Zugriff auf die Postfächer von den Exchange 2003 Front-End Server auf die neuen Exchange 2007 CAS Server umgestellt hatten, funktionierte im ersten Schritt soweit alles ohne Probleme. Nach einiger Zeit wollten wir allerdings testweise die Passwörter sowohl vor der Anmeldung (also am ISA Server) bzw. im OWA selbt unter "Optionen" ändern. Leider wird dies mit der Fehlermeldung 403 bzw. 404 quittiert, guckst du hier:

Ohne Anpassungen wird sich der Zustand auch nicht mehr ändern, dass Benutzer ihre Passwörter ändern können, solange ihre Postfächer noch auf Exchange 2003 Back-End Server liegen. Werden die Benutzer nach Exchange 2007 migriert ist der CAS Server für die Passwort-Änderung verantwortlich und führt dies auch ohne Probleme durch.

Natürlich gibt es Workarounds zu diesem Thema, guckst du hier:
http://telnetport25.wordpress.com/2008/05/08/windows-2008-iis-7-the-exchange-2007-cas-and-iisadmpwd/

Allerdings ist diese Vorgehensweise leider seitens Microsoft nicht offiziell supported, guckst du hier: http://msexchangeteam.com/archive/2008/12/09/450238.aspx

Somit ist die Devise, so schnell wie möglich die Benutzer nach Exchange 2007 zu migrieren, so dass die OWA Benutzer ihre Passwörter wieder ändern können.

Viele Grüße, Jens

Antispam Agent Handling

Hallo zusammen,

ich wollte mich in diesem Blogbeitrag ein wenig dem AntiSpam Modul von Exchange 2007/2010 widmen. Wenn emails durch das AntiSpam Modul blockiert oder in Quarantäne gestellt werden, sind genau diese email nicht über die Nachrichtenverfolgung auffindbar.
Emails die als Spam klassifiziert worden sind, können zwar über das Anti-Spam Log ermittelt werden bzw. die Details könnten angeschaut werden, aber sie können nicht an den ursprünglichen Empfänger weitergeleitet werden (im Falle von false positive). Der Absender müsste in diesem Fall die email erneut versenden.

Anbei ein Beispiel wir man im Log nach blockierten emails sucht:
Get-AgentLog where {$_.P1FromAddress -like "Absender@hotmail.com" -or $_.P2FromAddresses -like "Absender@hotmail.com" -and $_.reasondata -eq "9"}

Get-AgentLog -StartDate "25.03.2010" -EndDate "26.03.2010" where {$_.reasondata -eq "9"} > c:\antispam.txt

In diesem Beispiel sucht Exchange nach allen emails vom Absender "absender@hotmail.com" im Zeitraum vom 25.03.2010 bis 26.03.2010 und einen SCL Wert von 9 (also Spam) und gibt das Ergebnis in eine .txt Datei aus.

Viele Grüße, Jens

neue PFDAVADmin Version

Hallo zusammen,

Microsoft hat eine neue Version von PFDAVAdmin veröffentlicht mit dem nun deutlich besser Exchange 2007 bedient werden kann. PFADVAdmin funktioniert aber dennoch nicht (mehr) mit Exchange 2010, dahier WEBDAV als Dienst herausgenommen worden ist.

An updated version of the PFDAVAdmin tool has been released to the web. You can get it from the download center at this link: http://www.microsoft.com/downloads/details.aspx?familyid=635BE792-D8AD-49E3-ADA4-E2422C0AB424.
This update contains various bug fixes that have been made over the last three years (the prior version on the Download Center was from April of 2007). It also has some changes that make it work better against Exchange 2007. For instance, the old versions of PFDAVAdmin expected certain directory objects to be present for all Exchange servers. In Exchange 2007, some of those objects are only present with a CAS role. This resulted in a situation where PFDAVAdmin would only connect to Exchange 2007 mailbox servers that also had the CAS role. That problem is fixed in this version of PFDAVAdmin, which has no problem connecting to Exchange 2007 with only the mailbox role installed.
The dependency on .NET Framework 1.1 remains, which means you should run PFDAVAdmin from a workstation with Framework 1.1 installed - you should not install this old version of the framework on your Exchange servers, because it makes IIS unhappy.
PFDAVAdmin still cannot connect to Exchange 2010 servers, because WebDAV is gone from 2010. If you need similar functionality for Exchange 2010, use ExFolders instead.

Viele Grüße, Jens

Postfachdaten Recovery

Hallo zusammen,

mal wieder eine Anforderung gehabt die es wert ist sich in einem Blogeintrag zu widmen. Ein Benutzer hatte versehentlich seine "Gelöschten Elemente" im Outlook gelöscht und hatte dies erst 30 Tage nachher gemeldet, so dass es nicht mehr möglich war mit dem serverseitigen Papierkorb diese Daten zurückzuholen. Normalerweise sollte ja auch nicht die gelöschten Elemente als Archiv dienen, aber lassen wir das :)

Gesichert wurde und wird mit dem DPM 2007 Server. Beim Restore, auf das ich jetzt nicht näher eingehe da das klar sein dürfte wie das geht, ist es nur möglich die komplette Exchange Datenbank zurückzusichern, guckst du http://support.microsoft.com/kb/904845/en-us
Dies bedeutet somit, dass wir somit min. soviel Festplattenplatz auf der Platte benötigen wie eben die aktuell gesicherte Datenbank groß ist (Stichwort: Planung).

Sobald das Restore mittels DPM durchgeführt wurde ist die s.g. Recovery Storage Group anzulegen, guckst du http://www.msexchange.org/tutorials/Working-Recovery-Storage-Groups-Exchange-2007.html
In unserem Szenario wollten wir aber nicht das komplette Postfach zusammenführen bzw. kopieren, sondern die "gelöschten Elemente" in ein Unterordner zurücksichern. Daher hatten wir in der Exchange Management Shell foglenden Befehl ausgeführt um das Postfach in ein Unterordner namens Restore zurückzusichern:

Restore-Mailbox -Identity "John.Doe" -RSGDatabase "rsg\mailbox database" -rsgmailbox "John.Doe" -TargetFolder "Restore"

Der Benutzer hatte sich im nächsten Schritt die Daten selbstständig verschoben und daraufhin den Unterordner gelöscht.

Eine weitere Möglichkeit dedizierte Emails zurückzuholen ist hier sehr schön dokumentiert, guckst du http://edge.technet.com/Media/DPM-2007-how-to-do-individual-item-restore-for-Exchange/

Viele Grüße, Jens

Exchange Cross Forest Administration

Hallo zusammen,

ich hatte neulich eine Anforderung dass ein Administrator aus Forest A (Exchange 2003) Exchange Organisations Berechtigungen für Forest B (Exchange 2007) benötigt hatte. Es handelte sich hierbei um zwei komplett voneinander getrennte Gesamtstrukturen, die über einen Forest Trust verbunden sind. DNS usw. funktioniert naütrlich soweit bzw. war Voraussetzung.
Über die Exchange 2007 Verwaltungskonsole ist es allerdings nur möglich Benutzer aus dem lokalen Forest bzw. der Domäne hinzuzufügen und keine Cross Forest Benutzer.

Nach einige Recherchen habe ich dann folgenden Artikel gefunden, der das Problem schön beschreibt und gleichzeitig eine Lösung anbietet, guckst du technet.microsoft.com/en-us/library/bb232078%28EXCHG.80%29.aspx

Das ganze hatte nur den Haken, dass es einfach nicht funktioniert hatte. Folgende Passage hatte dann schlussendlich doch die Lösung gebracht, auch wenn es aus meiner Sicht recht unverständlich hinterlegt ist.

To perform the steps of this procedure in Forest A, the account you use must be delegated the following:
Membership in the Enterprise Admins group in Forest A

To perform the steps of this procedure in Forest B, the account you use must be delegated the following:
Membership in the Enterprise Admins group in Forest B

Weill heißen, mein Admin-Account aus Forest A muss zu den Domänen Admins in Forest B hinzugefügt werden und umgekehrt. Leichter gesagt als getan. Mein Admin Account aus Forest A muss zum Mitglied der "Administratoren" in der OU "Built-in" gemacht werden. Das ist dort die einzige Stelle wo ein Cross Forest Benutzer als Administrator hinzugefügt werden konnte, da es sich bei dieser Gruppe um eine domänenlokale Gruppe (siehe AGDLP) handelt. Es ist nicht möglich ein Benutzer aus einem fremden Forest in die Gruppen der Domänen-Admins oder Enterprise Admins hinzuzufügen.

Viele Grüße, Jens

Bestimmte Benutzer von GAL ausblenden

Hallo zusammen,

ich hatte diese Woche eine interessante Anforderung die auf den ersten Blick gar nicht gelöst werden kann. Nehmen wir an wir arbeiten alle bei Contoso. Contoso hat die Anforderung dass bestimmte Benutzer (z.B. interne Detektive, Fahnder usw.) nicht in der GAL angezeigt werden dürfen und nur in einer dedizierten Adressliste vorhanden sein dürfen.

Microsoft gibt klar vor, dass die eine Anpassung der GAL nicht supported ist, guckst du http://technet.microsoft.com/en-us/library/bb232068(EXCHG.80).aspx (You cannot edit the settings of the default GAL.)
Auch die Möglichkeit der s.g. Addresslist Segregation ist nicht möglich bzw. nicht im Exchange Standard und somit auch nicht supported, siehe http://technet.microsoft.com/de-de/library/bb936719(EXCHG.80).aspx (Unsupported: This configuration is one where companies may want to totally segregate their address lists and still have access to the Default Global Address List, or try to split the Global Address List (GAL) into two separate address lists. An example of this configuration would be a company with two groups of 500 users that belong to the Sales and Finance departments. Both groups are in the GAL, however the desire is to have everyone access the GAL except one group. If you are going to segregate your address lists, then they will be segregated. Attempting this configuration will cause problems with the check names functionality which will prevent users from creating Outlook profiles, and can also break the OAB Generation Process. This also allows Outlook users to see all of the Address Lists from within Outlook, which cannot be changed.)

Die Address List Segregation ist allerdings extrem aufwendig zu implementieren und ist auch erst ab Exchange 2007 (derzeit noch nicht für Exchange 2010) unterstützt. Sobald in der Exchange Organisation noch ein Exchange 2003 Server vorhanden wäre, wäre diese Schriftstück schon wieder obsolet, da nicht seitens Microsoft unterstützt.

Da die Segregation somit außen vor war/ist aufgrund der viel zu hohen Anforderungen und Implementierungszeit hatten wir eine andere, zündende Idee, wir verwenden öffentliche Ordner (die die länger leben als gedacht):

Es wird ein neuer Öffentlichen Ordner namens Microsoft angelegt, als Unterordner wird ein Kontakt-Öffentlichen Ordner angelegt, der wie die Adressliste heisst angelegt:













In diesem öffentlichen Kontaktordner (welcher über Berechtigungen gesteuert wird) werden dann die "versteckten Benutzer" angelegt. Dieser Kontaktordner bzw. dessen Kontakte werden nicht in der GAL angezeigt.
Benutzer die Berechtigungen auf dem öffentlichen Ordner haben, können sich diesen Ordner im Adressbuch mitanzeigen lassen. Dies wird folgendermaßen durchgeführt und ist für jeden Benutzer durchzufüren der an Delton emails senden muss:

Rechte Mousetaste auf "Microsoft" - "Eigenschaften" - Registerkarte "Outlook Adressbuch" - Haken setzen bei "Dieen Ordner als Email Adressbuch anzeigen"
















Daraufhin kann der Benutzer die Delton Benutzer aus dem Adressbuch auswählen:

Diese Lösung hat den Vorteil, dass sie a) von Microsoft supported ist und b) der Benutzer kann wie gewohnt weiterarbeiten.
Lediglich die Berechtigungen auf den öffentlichen Ordner muss gesetzt werden, für die Benutzer für die der Ordner sichtbar sein soll. Am besten ist hierzu eine Gruppe zu verwenden.

Viele Grüße, Jens

Windows Mobile: Verschlüsselung von Speicherkarten

Hallo,

Exchange 2007 bietet mittels Active Sync Richtlinien an Speicherkarten zu verschlüsseln. Das ist ne tolle Sache, allerdings sollte dennoch beachtet werden, dass nur neue Dateien verschlüselt werden. Die Daten die bereits vor der Richtlinie auf der Speicherkarte vorhanden waren sind und bleiben unverschlüsselt.

Viele Grüße,
Jens

Active Sync in einer Exchlange 2003/2007 Migration

Hallo zusammen,

in einer Exchange 2003/2007 Migration läuft es vom Vorgehen her so ab, dass zuerst die HUB/CAS Server umgestellt werden und erst zum Schluss die Postfächer von Exchange 2003 nach Exchange 2007 verschoben worden.

Für die bevorstehende CAS Migration haben wir uns auf den ISA Servern ein neues Zertifikat und eine Route eingerichtet, so dass wir parallel zum Live-Betrieb den Zugriff via Outlook, Outlook Anywhere, OWA, Active Sync usw. testen können. Bei den ersten Tests von Active Sycn ist uns aufgefallen, dass Active Sync nur dann funktioniert wenn das Postfach auf einem Exchange 2007 Mailbox Server liegt.

Sobald ich meinen Testbenutzer verwenden möchte, der auf Exchange 2003 liegt haben wir auf dem Endgerät immer wieder die Kennwortaufforderung erhalten, als ob wir das Kennwort nicht richtig hinterlegt hätten (was wir aber haben).

Die Lösung haben wir dann schlussendlich auf dem MSExchange Team Blog gefunden, guckst du hier: http://msexchangeteam.com/archive/2007/01/05/432079.aspx

Sobald die integrierte Windowsauthentifizierung auf dem Exchange 2003 Backend Server hinterlegt ist funktioniert auch sofort der Active Sync Zugriff über die Exchange 2007 CAS Infrastruktur.

Viele Grüße, Jens