Getrennte Benutzerpostfächer in PST exportieren

Heute wurde ich damit konfrontiert getrennte Postfächer auf einem Exchange 2010 Mailboxserver in eine .PST Datei zu exportieren.
Dies stelle sich nach den ersten versuchen, doch nicht so ganz einfach dar. Nach ein bisschen Recherche und ausprobieren bin ich zu folgender Lösung gekommen.

Da ihr standardmäßig nicht die Berechtigung zum Exportieren von Postfächern habt müsst ihr euch diese erst zuweisen.
Dies macht ihr mit dem Befehl:

New-ManagementRoleAssignment –Role „Mailbox Import Export“ –User <Username>

Wahlweise kann auch eine Gruppe hinzugefügt werden. Dann lautet der Befehl:

New-ManagementRoleAssignment –Role „Mailbox Import Export“ –Group <Groupname>

Damit die Änderungen wirksam werden muss die Shell einmal neugestartet werden!

Eine weitere Vorbereitung die ihr treffen müsst ein eine Freigabe zu erstellen, wo ihr gleich die PST Files erstellen lasst. Jetzt kann es losgehen.

Da der Befehl zum Exportieren von Postfächern leider nur aktive Postfächer exportieren kann müsst ihr für jedes getrennte Postfach einen „Dummy“ AD-User anlegen.

Am einfachsten gestaltet es sich natürlich wenn ihr den AD-User auch passend zum Postfach erstellt. Also bei einem Postfach von Max Mustermann sollte der AD-User ebenfalls Max Mustermann heißen. Wenn die AD-User angelegt sind kann man nun über die EMC die gentrennten Postfächer neu Verbinden.

Das neu Verbundene Postfach taucht nun wieder unter dem Punkt „Postfächer“.

Damit auch die Datenbanken alle aktualisiert sind führt bitte über die Shell noch folgenden Befehl aus:

Get-MailboxDatabase | Clean-MailboxDatabase

Jetzt können wir den eigentlichen Exportbefehl wie folgt absetzten:

New-MailboxExportRequest –Mailbox <Alias> -FilePath „<UNC-Pfad>\Datei.pst“

Den Status des Exports könnte ihr mit

Get-MailboxExportRequest

herausfinden.

Löschen von abgeschlossen Anforderungen funktioniert mit

Remove-MailboxExportRequest

Ich hoffe ich konnte euch weiter helfen.

Greetz

Stephan

Advertisements

DirectAccess mit Windows Server 2012

Vor einigen Tagen wurde ich zufällig mit dem Thema „DirectAccess“ konfrontiert. Da viel mir ein das ich diese Art der Einwahl in ein Firmennetz schon immer mal testen wollte. Nun habe ich mir die Zeit genommen und eine kleine Anleitung geschrieben.

In diesem „how-to“ beschreibe ich die Installation und Konfiguration eines Remotezugriffs-Servers (DirectAccess) hinter einem NAT-Router.

Folgendes habe ich bereits vorher erledigt:

  • Domänencontroller
  • Windows Server 2012 Memberserver
  • Windows 8 Client
  • Domänen-Administrator Zugang
  • Öffentliche IP mit DNS Record zu dieser IP

Das Szenario:

Ich habe einen Hyper-V Host auf Basis eines Windows Server 2012. Auf diesem laufen 2 virtuelle Maschinen, der DC und der DirectAccess-Server. Beides sind ebenfalls auf Basis Windows Server 2012. Alles hängt hinter einer Firewall. Die Domäne heißt „sv2013.local“

Die eigentliche Installation:

Auf dem zukünftigen DirectAccess Server fügt ihr die Rolle „Remotezugriff“ hinzu. Einfach mit Standard durch klicken.

Während der Installation legt bitte eine Sicherheitsgruppe in der Domäne an und fügt alle Clients die später „DirectAccess“ nutzen sollen hinzu. Meine Gruppe nennt sich „DirectAccessGroup“.

Weiter muss auf dem Domaincontroller noch das ISATAP Protokoll erlaubt werden. Dies könnt ihr mit folgendem Befehl tun.

dnscmd /config /globalqueryblocklist wpad

Nachdem die Installation fertig ist könnt ihr die Remotezugriffsverwaltung über den Server Manager starten.

Schritt 1:

 

Weiter

Füge die vorher erstelle Sicherheitsgruppe hinzu und Weiter.

Mit der oberen Einstellung prüfen die Clients später ob sie sich im internen Netz befinden oder nicht. Daran wird dann festgestellt ob der Client sich mit dem DirectAccess Server verbinden muss oder nicht. Weiter muss noch eine E-Mail Adresse eingetragen werden und ein Name der später als Netzwerkname am Client angezeigt wird. Hier „DirectAccessVPN“. Mit „Fertig stellen“ ist der erste Schritt abgeschlossen.

Schritt 2:

 

Bitte die öffentlich IP bzw. den DNS Namen eintragen auf die sich später die Clients einwählen.

Da ich keine eigene PKI habe, bleibt mir hier nur das „Eigene Zertifikat“.

Die Anmeldung soll später mit Benutzername und Kennwort passieren, daher erste Option. Weiter habe ich in meiner Demo Umgebung nur Windows 8 Clients. Das Verbinden mit Windows 7 erfordert mehr Aufwand, denn ich hier aber nicht beschreibe.

Die VPN Konfiguration kann so übernommen werden.

Schritt 3:

 

Für meine Demoumgebung wähle ich hier die zweite Option und der NLS-Server wird mit auf dem DirectAccess Server bereitgestellt. In Produktiven Umgebungen sollte dies immer vermieden werden, da im Falle eines Ausfalls des DA Servers keiner mehr arbeiten kann.

Weitere Infos unter:
http://technet.microsoft.com/en-us/library/gg315317.aspx

Der Rest kann so übernommen werden.

Schritt 4:

Falls ihr nicht möchtet das DirectAccess Clients Zugriff auf alle Server haben, kann man hier mithilfe von Gruppen nur bestimmte Server zulassen. Ich habe mich für vollen Zugriff entschieden.

Anschließend müsst ihr die Konfiguration noch anwenden.

Kontrollieren und Anwenden.

Nun könnt ihr über das Dashboard einige Infos bekommen.

Hier sollte alles „grün“ sein.

Der Server ist nun fertig. Weiter geht’s mit dem Client.

Windows 8 Client

Damit der Client sich auf später Verbinden kann muss auf der Firewall noch der Port 443 geöffnet werden und die externe IP weitergeleitet werden auf den DA Server.

Der Windows 8 Client bekommt nach einem Neustart die GPO zugeteilt (Vorausgesetzt er ist Mitglied der Gruppe „DirectAccessGroup“) und hat somit alle Einstellungen die er brauch. Wenn der Client sich nun im externen Netz befindet und er den NLS Server nicht erreichen kann versucht er sich über die öffentliche IP mit dem DA Server zu verbinden.

Unter den Verbindungen in Windows 8 taucht dann „DirectAccessVPN Verbunden“ auf.

 

Weitere Infos:

http://www.msxfaq.de/verschiedenes/directaccess2012.htm

http://syscomlab.blog.com/2012/09/directaccess-for-windows-server-2012-guide/

Greetz

Stephan

Update Exchange 2013 CU1 auf CU2

Hallo,

heute habe ich in meiner Demo-Umgebung das neue Exchange 2013 CU2 Update getestet.

Meine Demo-Umgebung:

– Windows Server 2012 Hyper-V Host

– VM mit Server 2012 / Exchange 2013 CU1

Hier ein kleines „how-to“:

Das Suchen nach Updates habe ich hier ausgelassen da ich in der Demo vom Internet getrennt bin.
Sonst sicherlich ein gute Idee, vorher nach Updates zu suchen.

Weiter

Lizenzvereinbarung Akzeptieren und Weiter

Da ich leider vergessen habe die Office Filter Packs zu installieren,
gibt er hier eine Warnung aus. Es geht auch ohne!

Nun installiert er das Update was je nach Leistung schon dauern kann.

Bei mir war es in ca. 60 Minuten fertig.

Greetz
Stephan

Exchange 2013 CU2 Released

Hallo,

gestern wurde Exchange 2013 CU2 veröffentlicht:

http://www.microsoft.com/en-us/download/details.aspx?id=39609

Hier sind die Release Notes:

Changes in Exchange 2013 RTM CU2

In addition to bug fixes, Exchange 2013 RTM CU2 introduces enhancements in the following areas.

  • Per-server database support
  • OWA Redirection
  • High Availability
  • Managed Availability
  • Cmdlet Help
  • OWA Search Improvements
  • Malware Filter Rules

Per-Server Database Support

As mentioned previously, Exchange 2013 RTM CU2 increases the per-server database support from 50 databases to 100 databases in the Enterprise Edition of the product. Please note that this architectural change may not provide any additional scalability as CPU may be a bottleneck, thereby limiting the number of mailboxes you can deploy per-server.

As promised, the Exchange 2013 Server Role Requirements Calculator has been updated for this architectural change.

OWA Redirection

Depending on your deployment model, Exchange 2013 RTM CU1 supported the following redirection or proxy scenarios:

  1. In environments where Exchange 2013 and Exchange 2010 coexist, Exchange 2013 CAS proxies OWA requests to Exchange 2010 CAS for Exchange 2010 mailboxes.
  2. In environments where Exchange 2013 and Exchange 2007 coexist, Exchange 2013 CAS redirects the request to the Exchange 2007 CAS infrastructure’s ExternalURL. While this redirection is silent, it is not a single sign-on event.
  3. In native Exchange 2013 environments:
    1. Exchange 2013 CAS proxies the OWA request directly to the Exchange 2013 Mailbox server when in a single site.
    2. Exchange 2013 CAS proxies the OWA request directly to the Exchange 2013 Mailbox server when the Mailbox server exists in a different site and the CAS infrastructure in the target site has no ExternalURL defined.
    3. Exchange 2013 CAS proxies the OWA request directly to the Exchange 2013 Mailbox server when the Mailbox server exists in a different site and the CAS infrastructure in the target site has an ExternalURL that matches the source site’s ExternalURL.
    4. Exchange 2013 CAS redirects the OWA request to the CAS infrastructure in the target site when the target site’s ExternalURL does not match the source site’s ExternalURL. While this redirection is silent, it is not a single sign-on event.

Exchange 2013 RTM CU2 changes this behavior by providing a single sign-on experience when Forms-Based Authentication (FBA) is used on the source and destination OWA virtual directories by issuing back to the web browser a hidden FBA form with the fields populated. This hidden form contains the same information as what the user had originally submitted to the source CAS FBA page (username, password, public/private selector) as well as, a redirect to the target Exchange specific path and query string. As soon as this form is loaded it is immediately submitted to the target URL. The result is the user is automatically authenticated and can access the mailbox data.

Many of you may be familiar with this functionality in Exchange 2010 SP2. However, there are differences in the Exchange 2013 RTM CU2 implementation:

  1. Silent redirection is the default behavior in Exchange 2013, meaning that if FBA is enabled on source and target OWA virtual directories, the redirection will also be a single sign-on event.
  2. You can disable silent redirection on the source CAS via the web.config file located at <ExchangeSetupDir>\FrontEnd\HttpProxy\owa by adding the following line in the <appSettings>section:<add key=”DisableSSORedirects” value=”true” />

High Availability

Exchange 2013 RTM CU2 introduces a new service, the DAG Management Service. The DAG Management service contains non-critical code that used to reside in the Replication service. This change does not introduce any additional complexities in event reporting, either – events are written into the Application event log with the source of MSExchangeRepl and crimson channel.

Managed Availability

In addition to improvements in various probes and monitors, there have been changes to the responder throttling framework. Prior to Exchange 2013 RTM CU2, many responders were only throttled per-server (e.g., RestartService). Now, these responders are throttled per group. For example, originally RestartService was throttled based on the number of occurrences that occurred on a server; in Exchange 2013 RTM CU2, RestartService can execute every 60 minutes DAG-wide, with a maximum of 4 restarts per day DAG-wide.

RecoveryAction Enabled Per Server Per Group
Minutes Between Actions Max Allowed Per Hour Max Allowed Per Day Minutes Between Actions Max Allowed Per Day
ForceReboot True 720 N/A 1 600 4
SystemFailover True 60 N/A 1 60 4
RestartService True 60 N/A 1 60 4
ResetIISPool True 60 N/A 1 60 4
DatabaseFailover True 120 N/A 1 120 4
ComponentOffline True 60 N/A 1 60 4
ComponentOnline True 5 12 288 5 Large
MoveClusterGroup True 240 N/A 1 480 3
ResumeCatalog True 5 4 8 5 12
WatsonDump True 480 N/A 1 720 4

Cmdlet Help

Exchange 2013 RTM CU2 introduces the capability for administrators to get updates to Exchange Management Shell cmdlets without needing to deploy a new service pack or cumulative update. Administrators can launch the Exchange Management Shell and run the Update-ExchangeHelp cmdlet to update their local Shell help.

OWA Search Improvements

Previously searching for keywords within OWA did not give indications of the location of the keyword in the search result set. Exchange 2013 RTM CU2 improves OWA’s search results highlighting in three ways:

  1. Conversation items are auto-expanded that have hits in them.
  2. Whenever you search for a term and select a conversation from the result list, OWA will move the scroll position of the reading pane so that the first item part with that search term is in view.
  3. Hit navigation within a conversation – you can jump between search hits quickly using a control built into the reading pane.

Malware Filter Rules

Exchange 2013 RTM CU2 introduces the –MalwareFilterRule cmdlets. You can use the –MalwareFilterRule cmdlets to apply custom malware filter policies to specific users, groups, or domains in your organization. Custom policies always take precedence over the default company-wide policy, but you can change the priority (that is, the running order) of your custom policies.

(Quelle:http://blogs.technet.com/b/exchange/archive/2013/07/09/released-exchange-server-2013-rtm-cumulative-update-2.aspx )

Greetz

Stephan

Systempartition unter Server 2003 vergrößern

Gestern wurde ich von einem Kollegen gefragt wie man unter Server 2003 eine Systempartition vergrößern kann. Leider geht dies nicht wie bei Server 2008 in der Datenträgerverwaltung. Man muss hier auf „Third Party Tools“ zurück greifen.

Eins dieser Tools ist ExtPart von Dell.

Hier eine kleine Anleitung ( Englisch ):

Extract the Tool to the Server and open the command prompt.
Set the Focus to the Location where ExtPart is located.
Bild 6.jpg

After you typed in „ExtPart“ without any Paramters, you will be asked for the Volume to extend. This is usually C:
Bild 7.jpg

Now the Tool will ask you to define the Size ( MB ) you`ll add to the Partition. In my case 3000 MB. So type „3000„.
Bild 8.jpg
This is all. Reboot the System and have fun.

Please make sure that you Backup is working and use this intructions at your own risk.