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"
Montag, 24. November 2014
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.
Abonnieren
Posts (Atom)