Die digitale Welt stellt uns vor ganz neue Herausforderungen. Eine digitale Unordnung fällt nicht so schnell auf wie eine Digitale. Doch auch in der digitalen Welt ist Ordnung die halbe Miete. Digitale Unordnung findet man oft in der Active Directory. Server / Computer die ausser Betrieb genommen wurden oder Userobjekte von Mitarbeitern welche die Firma verlassen haben geistern oft noch lange in der AD umher und Ordnung zu schaffen ist sehr zeitraubend. Zum Glück hat uns Microsoft in den neueren OS-Versionen eine Power Shell Untersützung für die AD spendiert.
Nicht mehr verwendete Computerobjekte in der AD finden:
Eine Möglichkeit veraltete Computerobjekte in der AD zu finden ist zu schauen wann sich ein Computer zuletzt an der AD angemeldet hat. Dies kann über 2 verschiedene Parameter geschehen:
Get-ADComputer <Computer Name> -LastLogon
Montag, 24. November 2014
Finde Computerobjekte in deiner AD
Seit wir auch im AD-Umfeld mit Power Shell arbeiten können haben sich diverse neue Möglichkeiten ergeben um die eigene AD zu managen. Hier mal ein paar befehle um Computer oder Server in der AD zu finden und das Ergebnis nach bedarf zu filtern:
Finde alle Computer in der AD (Ausgabe in ein CSV):
Get-ADComputer -Filter { OperatingSystem -Like '*' } | Select -Exp Name | Out-File "C:\Scripts\Find_all_Computers_with_OS\All_Computers.csv"
Finde alle Windows Server in der AD (Ausgabe in ein CSV):
Get-ADComputer -Filter { OperatingSystem -Like '*Windows Server*' } | Select -Exp Name | Out-File "C:\Scripts\Find_all_Computers_with_OS\All_Windows_Servers.csv"
Finde alle Computer in der AD (Ausgabe in ein CSV):
Get-ADComputer -Filter { OperatingSystem -Like '*' } | Select -Exp Name | Out-File "C:\Scripts\Find_all_Computers_with_OS\All_Computers.csv"
Finde alle Windows Server in der AD (Ausgabe in ein CSV):
Get-ADComputer -Filter { OperatingSystem -Like '*Windows Server*' } | Select -Exp Name | Out-File "C:\Scripts\Find_all_Computers_with_OS\All_Windows_Servers.csv"
Freitag, 26. September 2014
Remote Wipe oder Mobile Device Verwaltung für User deaktivieren
Seit Exchange 2010 können User ihre Mobile Devices über OWA selbst verwalten. Diese Funktion erlaubt den Usern auch für ihre Mobile Devices selbst Remote Wipes durchzuführen. Dies ist so nicht immer gewünscht und kann mittels einer OWA Mailbox Policy eingeschränkt werden.
Eine Default OWA Mailbox Policy wird bei der Installation von Exchange erstellt, diese OWA Mailbox Policy wird aber nicht automatisch auf User angewendet. Es kann also die Default OWA Mailbox Policy angepasst oder eine neue OWA Mailbox Policy erstellt werden.
Mit folgendem Befehl kann der/die Name/n der bestehenden OWA Mailbox Policy/s ausgelesenen werden:
Get-OwaMailboxPolicy | select name
Ob einem User schon eine OWA Mailbox Policy zugewiesen ist kann mit folgenden Befehl geprüft werden:
Get-CASMailbox b.brunner | FL OWAMailboxPolicy
Um die Mobile Verwaltung für User in OWA zu unterbinden kann die OWA Mailbox Policy folgendermassen angepasst werden:
Set-OwaMailboxPolicy "Default" -ActiveSyncIntegrationEnabled:$false
Nun muss die OWA Mailbox Policy nur noch einem User zugewiesen werden:
Set-CASMailbox b.brunner -OwaMailboxPolicy "Default"
Bei der nächsten Anmeldung des Users in OWA ist der Navigationspunkt "mobile devices" nicht mehr ersichtlich.
Eine Default OWA Mailbox Policy wird bei der Installation von Exchange erstellt, diese OWA Mailbox Policy wird aber nicht automatisch auf User angewendet. Es kann also die Default OWA Mailbox Policy angepasst oder eine neue OWA Mailbox Policy erstellt werden.
Mit folgendem Befehl kann der/die Name/n der bestehenden OWA Mailbox Policy/s ausgelesenen werden:
Get-OwaMailboxPolicy | select name
Ob einem User schon eine OWA Mailbox Policy zugewiesen ist kann mit folgenden Befehl geprüft werden:
Get-CASMailbox b.brunner | FL OWAMailboxPolicy
Um die Mobile Verwaltung für User in OWA zu unterbinden kann die OWA Mailbox Policy folgendermassen angepasst werden:
Set-OwaMailboxPolicy "Default" -ActiveSyncIntegrationEnabled:$false
Nun muss die OWA Mailbox Policy nur noch einem User zugewiesen werden:
Set-CASMailbox b.brunner -OwaMailboxPolicy "Default"
Bei der nächsten Anmeldung des Users in OWA ist der Navigationspunkt "mobile devices" nicht mehr ersichtlich.
Dienstag, 23. September 2014
Exchange Shell Befehle remote ausführen
Wenn Exchange Shell Befehle von einem Server ohne Exchange Installation ausgeführt werden sollen kann folgendes verwendet werden:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<URL virtuelles Verzeichniss Powershell>/powershell -Authentication Kerberos
Import-PSSession $Session -AllowClobber
<COMMANDS>
Remove-PSSession $Session
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<URL virtuelles Verzeichniss Powershell>/powershell -Authentication Kerberos
Import-PSSession $Session -AllowClobber
<COMMANDS>
Remove-PSSession $Session
Exchange 2013 - Mobile Device Policy zuweisen
Um eine Mobile Device Policy mehreren Benutzern zuzuweisen können folgende Cmdlets verwendet werden:
Allen Benutzern im AD die gleiche Mobile Device Policy zuweisen:
Get-CASMailbox -ResultSize Unlimited | Where {$_.ActiveSyncMailboxPolicyIsDefaulted -eq $false} | Set-CASMailbox -ActiveSyncMailboxPolicy "My_MPR"
Allen Benutzern in einer OU eine Mobile Device Policy zuweisen:
Get-Mailbox -ResultSize Unlimited | Where {$_.OrganizationalUnit -eq "my.domain.com/iTrain/Mitarbeiter" -and $_.RecipientType -eq "UserMailbox"} | Set-CASMailbox -ActiveSyncMailboxPolicy "My_MPR"
Allen Benutzern im AD die gleiche Mobile Device Policy zuweisen:
Get-CASMailbox -ResultSize Unlimited | Where {$_.ActiveSyncMailboxPolicyIsDefaulted -eq $false} | Set-CASMailbox -ActiveSyncMailboxPolicy "My_MPR"
Allen Benutzern in einer OU eine Mobile Device Policy zuweisen:
Get-Mailbox -ResultSize Unlimited | Where {$_.OrganizationalUnit -eq "my.domain.com/iTrain/Mitarbeiter" -and $_.RecipientType -eq "UserMailbox"} | Set-CASMailbox -ActiveSyncMailboxPolicy "My_MPR"
Donnerstag, 21. August 2014
Anmeldung an Exchange 2013 EAC mit internem Zertifikat nicht möglich
Unser gute Franky hat einen guten Blogeintrag zum Thema interne Zertifikate für Exchange 2013 verfasst: http://www.frankysweb.de/exchange-2013-san-zertifikat-und-interne-zertifizierungsstelle-ca/
Den Tipp von Franky habe ich schon oft benutzt, vor allem in Umgebungen mit einer .local Domain.
Nun habe ich bei einem Kunden mal wieder die interne CA bemüht um die CAS Kommunikation intern damit abzusichern. Nach Anleitung von Franky habe ich eine Zertifikatsvorlage erstellt und damit ein Zertifikat für die Exchange Server ausgestellt.
Nachdem wir dem Zertifikat den Dienst IIS zugewiesen haben konnten wir uns erstaunlicherweise nicht mehr an der EAC anmelden. Also haben wir über den IIS wieder das öffentliche Wildcard-Zertifikat zugewiesen. Siehe da, die Anmeldung an der EAC war wieder möglich.
Den Tipp von Franky habe ich schon oft benutzt, vor allem in Umgebungen mit einer .local Domain.
Nun habe ich bei einem Kunden mal wieder die interne CA bemüht um die CAS Kommunikation intern damit abzusichern. Nach Anleitung von Franky habe ich eine Zertifikatsvorlage erstellt und damit ein Zertifikat für die Exchange Server ausgestellt.
Nachdem wir dem Zertifikat den Dienst IIS zugewiesen haben konnten wir uns erstaunlicherweise nicht mehr an der EAC anmelden. Also haben wir über den IIS wieder das öffentliche Wildcard-Zertifikat zugewiesen. Siehe da, die Anmeldung an der EAC war wieder möglich.
Freitag, 8. August 2014
Exchange Migrationen - Übernahme der internen Relay Konnektoren
Die meisten Firmen mit einer Exchange Umgebung haben auf ihren Exchange Servern spezielle Empfangs-Konnektoren konfiguriert welche es internen Systemen erlauben Mails über den Exchange Server zu senden, ohne sich authentifizieren zu müssen. Wie man solche Empfangs-Konnektoren konfiguriert habe ich ein einem früheren Blogpost erläutert: Exchange 2013 - Interner Relay Konnektor erstellen
In diesem Post will ich eine Möglichkeit aufzeigen, wie solche Konnektoren bei einer Migration einfach übernommen werden können.
In einem ersten Schritt werden die erlaubten IPs, welche den Konnektor verwenden dürfen, in eine Variable geschrieben:
$ips = (Get-ReceiveConnector "SRVEXC01\Internal Relay").RemoteIPRanges
SRVEXC01 = Name des Exchange Servers
Internal Relay = Name des Empfangs-Konnektors
Nun kann der neue Empfangs-Konnektor über die Shell erstellt werden. Dabei werden die Remote IPs mit Hilfe der Variable eingefügt:
New-ReceiveConnector -TransportRole FrontendTransport -Name "Internal Relay" –Server "SRVEXCNEW01” -Usage Custom -AuthMechanism ExternalAuthoritative -PermissionGroups ExchangeServers,ExchangeLegacyServers,AnonymousUsers -Bindings 0.0.0.0:25 -RemoteIPRanges $ips
Welche Parameter es für das Cmdlet New-ReceiveConnector gibt ist übersichtlich auf TechNet aufgelistet: New-ReceiveConnector
In diesem Post will ich eine Möglichkeit aufzeigen, wie solche Konnektoren bei einer Migration einfach übernommen werden können.
In einem ersten Schritt werden die erlaubten IPs, welche den Konnektor verwenden dürfen, in eine Variable geschrieben:
$ips = (Get-ReceiveConnector "SRVEXC01\Internal Relay").RemoteIPRanges
SRVEXC01 = Name des Exchange Servers
Internal Relay = Name des Empfangs-Konnektors
Nun kann der neue Empfangs-Konnektor über die Shell erstellt werden. Dabei werden die Remote IPs mit Hilfe der Variable eingefügt:
New-ReceiveConnector -TransportRole FrontendTransport -Name "Internal Relay" –Server "SRVEXCNEW01” -Usage Custom -AuthMechanism ExternalAuthoritative -PermissionGroups ExchangeServers,ExchangeLegacyServers,AnonymousUsers -Bindings 0.0.0.0:25 -RemoteIPRanges $ips
Welche Parameter es für das Cmdlet New-ReceiveConnector gibt ist übersichtlich auf TechNet aufgelistet: New-ReceiveConnector
Installationsprobleme Exchange 2013 - Check whether this is a valid user account
Bei der Vorbereitung einer AD für die Installation von Exchange 2013 wurde mir bei der Ausführung des Befehls "Setup /PrepareAD" folgende Fehlermeldung angezeigt:
Active Directory must be prepared with 'Setup /PrepareAD'. However, the current user account doesn't have the permissions required even though it's a member of the 'Enterprise Admins' group. Check whether this is a valid user account.
Die Meldung ist mal wieder nicht besonders Aussagekräftig. "Du hast alles richtig gemacht aber irgendwas stimmt noch immer nicht, rate doch was es ist ;-)"
Nach längerer Suche haben wir dann das Problem gefunden. Wahrscheinlich durch ein etwas zu ambitioniertes Harding der Domäne wurde die "Default Domain Controller Policy" angepasst. Normalerweise wird über die "Default Domain Controller Policy" den Administratoren das Recht "manage auditing and security log" vergeben.
Durch die Berechtigung der Administratoren können bei der Installation von Exchange auch die Exchange Server eingetragen werden. Bei diesem Kunden war nun die Berechtigung für Administratoren entfernt. Dies war der Grund für die Fehlermeldung. Nachdem der User, unter welchem wir Exchange installieren wollten, diese Berechtigung erhalten hat (gpudate /force) klappte die Vorbereitung der AD ohne Probleme.
Active Directory must be prepared with 'Setup /PrepareAD'. However, the current user account doesn't have the permissions required even though it's a member of the 'Enterprise Admins' group. Check whether this is a valid user account.
Die Meldung ist mal wieder nicht besonders Aussagekräftig. "Du hast alles richtig gemacht aber irgendwas stimmt noch immer nicht, rate doch was es ist ;-)"
Nach längerer Suche haben wir dann das Problem gefunden. Wahrscheinlich durch ein etwas zu ambitioniertes Harding der Domäne wurde die "Default Domain Controller Policy" angepasst. Normalerweise wird über die "Default Domain Controller Policy" den Administratoren das Recht "manage auditing and security log" vergeben.
Durch die Berechtigung der Administratoren können bei der Installation von Exchange auch die Exchange Server eingetragen werden. Bei diesem Kunden war nun die Berechtigung für Administratoren entfernt. Dies war der Grund für die Fehlermeldung. Nachdem der User, unter welchem wir Exchange installieren wollten, diese Berechtigung erhalten hat (gpudate /force) klappte die Vorbereitung der AD ohne Probleme.
Mittwoch, 26. März 2014
Exchange 2010: Outlook Verbindung nach Reboot nicht möglich
Bei einer Migration auf Exchange 2010 bin ich kürzlich auf ein spezielles Phänomen gestossen. Nach erfolgreicher Installation von Exchange 2010 haben wir ein Testpostfach auf den neuen Exchange 2010 verschoben. Nach der Verschiebung hat Outlook seine neue Konfiguration über den Autodiscoverdienst ohne Probleme erhalten. Doch der Start von Outlook klappte nicht. Mit aktiviertem Cache-Modus erhielten wir folgende Fehlermeldung:
Ihre Standard-E-Mail-Ordner können nicht geöffnet werden. Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendatei (.ost) synchronisieren können, müssen Sie eine Verbindung mit Microsoft Exchange mit ihrem aktuellen Profil herstellen.
Wenn wir den Cache-Modus deaktivierten bekamen wir eine Fehlermeldung die recht bizarr wirkt:
Ihre Standard-E-Mail-Ordner können nicht geöffnet werden. Die Datei "C:\Users\Username\AppData\Local\Microsoft\Outlook\Username@domain.ch - Outlook.ost" ist keine Outlook-Datendatei (OST).
Ihre Standard-E-Mail-Ordner können nicht geöffnet werden. Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendatei (.ost) synchronisieren können, müssen Sie eine Verbindung mit Microsoft Exchange mit ihrem aktuellen Profil herstellen.
Wenn wir den Cache-Modus deaktivierten bekamen wir eine Fehlermeldung die recht bizarr wirkt:
Ihre Standard-E-Mail-Ordner können nicht geöffnet werden. Die Datei "C:\Users\Username\AppData\Local\Microsoft\Outlook\Username@domain.ch - Outlook.ost" ist keine Outlook-Datendatei (OST).
Mittwoch, 26. Februar 2014
Service Pack 1 für Exchange 2013 released
EDIT: Vorsicht - Die ersten Probleme mit dem SP1 sind schon aufgetaucht: http://eightwone.com/2014/03/05/exchange-2013-sp1-transport-agent-fix/
Gestern (25.02.2014) wurde das SP1 für Exchange 2013 released. Das Service Pack wurde von vielen sehnlichst erwartet. Nicht unbedingt aus technischen Gründen, sondern eher weil viele eine Migration auf eine neue Exchange Version erst nach erscheinen des ersten SPs ins Auge fassen, auch wenn schon 3 CUs erschienen sind.
Folgendes sind die spannenden Neuerungen welche mit dem SP1 dazu kommen:
Gestern (25.02.2014) wurde das SP1 für Exchange 2013 released. Das Service Pack wurde von vielen sehnlichst erwartet. Nicht unbedingt aus technischen Gründen, sondern eher weil viele eine Migration auf eine neue Exchange Version erst nach erscheinen des ersten SPs ins Auge fassen, auch wenn schon 3 CUs erschienen sind.
Folgendes sind die spannenden Neuerungen welche mit dem SP1 dazu kommen:
- Installation des Exchange 2013 auf einen Server 2012 R2 wird nun unterstützt
- Domain Controllers unter Server 2012 R2 werden nun unterstützt
- Domain oder Forest functional Level 2012 R2 wird nun unterstützt
- MAPI over HTTP wurde als zusätzliches Protokoll für Clientverbindungen hinzugefügt
- DLP Richtlinien Tipps werden nun auch in OWA angezeigt
- EDGE Rolle wurde hinzugefügt
und noch so einiges mehr. Weitere Informationen windet ihr auf folgenden Seiten:
Freitag, 17. Januar 2014
Exchange 2013 Training
Die iTrain GmbH (welche mein Arbeitgeber ist) bietet immer wieder Exchange Kurse an. Falls jemand Interesse an einer solchen Schulung hat, findet ihr Informationen und Termine auf unserer Website:
http://www.itrain.ch/de/it-education
http://www.itrain.ch/de/it-education
Exchange 2013 auf Server 2012: Probleme beim erstellen einer DAG
Wenn Exchange 2013 auf einem Server 2012 installiert ist, gibt es Probleme beim Bilden einer DAG. Die Erstellung der DAG ist möglich, doch wenn man versucht Mailbox Server zur DAG hinzuzufügen kommt eine Fehlermeldung.
Um das Problem zu beheben, muss der FQDN im AD Clusterobjekt von Hand hinzugefügt werden.
Wenn man das AD-Objekt anschaut, sieht man, dass das Feld "DNS-Name" leer ist:
Es ist aber nicht möglich, direkt in das Feld rein zu schreiben. Dies muss über die Registerkarte "Attribute Editor" gemacht werden. Das zu befüllende Attribut heisst "dNSHostName":
Dies alleine löst aber das Problem noch nicht. Die Berechtigungen auf dem Objekt stimmen auch noch nicht. Wenn man im jetzigen Zustand versucht Mailbox Server zur DAG hinzuzufügen, bekommt man eine Fehlermeldung die besagt, dass der Zugriff verweigert wurde. Um dies zu beheben, muss man unter der Registerkarte "Security" der Gruppe "Exchange Trusted Subsystems" noch "Full Access" geben:
Nachdem dies erledigt ist, ist das Problem aber noch immer nicht vollständig gelöst. Im letzten Schritt muss das Objekt auch noch deaktiviert werden. Nun klappt es auch mit dem Hinzufügen von Mailbox Servern zur DAG.
Ich finde es doch sehr verwunderlich, dass dies auch nach dem Erscheinen des CU3 noch nicht behoben wurde...
Um das Problem zu beheben, muss der FQDN im AD Clusterobjekt von Hand hinzugefügt werden.
Wenn man das AD-Objekt anschaut, sieht man, dass das Feld "DNS-Name" leer ist:
Es ist aber nicht möglich, direkt in das Feld rein zu schreiben. Dies muss über die Registerkarte "Attribute Editor" gemacht werden. Das zu befüllende Attribut heisst "dNSHostName":
Dies alleine löst aber das Problem noch nicht. Die Berechtigungen auf dem Objekt stimmen auch noch nicht. Wenn man im jetzigen Zustand versucht Mailbox Server zur DAG hinzuzufügen, bekommt man eine Fehlermeldung die besagt, dass der Zugriff verweigert wurde. Um dies zu beheben, muss man unter der Registerkarte "Security" der Gruppe "Exchange Trusted Subsystems" noch "Full Access" geben:
Nachdem dies erledigt ist, ist das Problem aber noch immer nicht vollständig gelöst. Im letzten Schritt muss das Objekt auch noch deaktiviert werden. Nun klappt es auch mit dem Hinzufügen von Mailbox Servern zur DAG.
Ich finde es doch sehr verwunderlich, dass dies auch nach dem Erscheinen des CU3 noch nicht behoben wurde...
Montag, 16. Dezember 2013
Exchange ESE Performance: Spanender Blog-Post von Michel de Rooij
Wir bekommen von Microsoft bei jeder neuen Exchange Version neue Zahlen zu Performance-Verbesserung auf der DB-Seite vorgesetzt. Michel de Rooij hat sich nun mal die Mühe gemacht und die Performance von Exchange 2010 und 2013 im LAB verglichen. Hier sein äusserst spannender Blog-Post zum Thema:
http://eightwone.com/2013/12/16/exchange-storage-performance-2010-versus-2013/
Ich wünsche allen Interessierten viel Spass beim lesen.
http://eightwone.com/2013/12/16/exchange-storage-performance-2010-versus-2013/
Ich wünsche allen Interessierten viel Spass beim lesen.
Freitag, 13. Dezember 2013
Exchange DAG Cluster Fehler 1196 (Source Microsoft-Windows-FailoverClustering)
Normalerweise muss der Failover Cluster Manager für die Verwaltung einer DAG nicht bemüht werden. Doch wenn ich mir eine Exchange Umgebung anschaue will ich natürlich auch immer wissen ob in den Clusterereignissen Fehler zu finden sind.
Häufig treffe ich dann auf folgenden Fehler:
Protokollname: System
Quelle: Microsoft-Windows-FailoverClustering
Datum: 13.12.2013 11:50:42
Ereignis-ID: 1196
Aufgabenkategorie: Netzwerknamenressource
Ebene: Fehler
Schlüsselwörter:
Benutzer: SYSTEM
Computer: EXCLAB-MBX01.mydomain.ch
Beschreibung:
Die Cluster-Netzwerknamensressource "Clustername" konnte mindestens einen dazugehörigen DNS-Namen nicht registrieren. Ursache:
Der DNS-Vorgang wurde abgelehnt.
Häufig treffe ich dann auf folgenden Fehler:
Protokollname: System
Quelle: Microsoft-Windows-FailoverClustering
Datum: 13.12.2013 11:50:42
Ereignis-ID: 1196
Aufgabenkategorie: Netzwerknamenressource
Ebene: Fehler
Schlüsselwörter:
Benutzer: SYSTEM
Computer: EXCLAB-MBX01.mydomain.ch
Beschreibung:
Die Cluster-Netzwerknamensressource "Clustername" konnte mindestens einen dazugehörigen DNS-Namen nicht registrieren. Ursache:
Der DNS-Vorgang wurde abgelehnt.
Freitag, 6. Dezember 2013
Exchange 2013 - DAG Netzwerke für Clients und Replikation trennen
Auch unter Exchange 2013 ist es für eine DAG möglich, die Netzwerke für den Clientzugriff und die DAG Replikation zu trennen. Wie dies eingerichtet wird, zeige ich in diesem Post.
Vorbereitung
Grundsätzlich müssen die MBX Server, die Mitglied der DAG sind mal zwei Netzwerkkarten haben, um die Netze trennen zu können. Ich habe mir dazu auf dem Hyper-V Host einen privaten virtuellen Switch erstellt. Unter Hyper-V bedeutet ein privater virtueller Switch, dass nur VM's die mit dem Switch verbunden sind, miteinander kommunizieren können. Auch der Hyper-V Host selbst kommt nicht an das Netzt ran. Also also ob man zwei Hardware Server über einem Switch miteinander verbindet.
Abonnieren
Posts (Atom)