Verbindet man Outlook für Mac von extern mit einem Exchange wird über den AutoDiscover-Mechanismus der Servername automatisch konfiguriert – bzw. geändert.

Problematisch ist es aber wenn hier der lokale Name des Exchange-Servers eingetragen wird – und somit keine Verbindung mehr zustande kommt.

Dieses Verhalten von Outlook kann man aber deaktiveren:

1) Outlook öffnen

2) AppleScript Editor öffnen (Script Editor.app in Programme/Dienstprogramme)

3) folgendes Script ausführen

tell application "Microsoft Outlook"
set background autodiscover of every exchange account to false
end tell

Danach den Servernamen im Outlook nochmal auf den externen Namen setzten – jetzt sollte der Servername nicht mehr geändert werden und die Verbindung funktionieren!

Wenn man auf einem Windows Server das Dedup-Feature einschaltet kann es passieren, dass der ChunkStore (dieser befindet sich in dem Ordner „System Volume Information“) in dem die Informationen für das Dedup gespeichert werden immer weiter wächst und so riesig wird das er teilweise den ganzen freien Platz auf dem Volume verbraucht.

Das kann man aber über einen DedupJob aber wieder fixen -hier am Beispiel eines Volumes F: :

eine Powershell als Administrator öffnen

und

Start-DedupJob -Volume “F:” -Type GarbageCollection -Memory 50

man kann mit

Get-DedupJob

überprüfen wie weit der Job schon ist.

Hilft dies nicht ist eine Möglichkeit noch die Deduplizierung rückgänging zu machen.

Dazu lässt man Dedup auf dem Volume aktiviert – deaktiviert aber die Hintergrundaktivität

Set-DedupSchedule BackgroundOptimization -enable $false

Start-DedupJob -Volume „F:“ -Type Unoptimization

Start-DedupJob -Volume “F:” -Type GarbageCollection

danach sollte der Chunk-Ordner weg sein – dann kann dedup bei Bedarf wieder aktiviert werden.

Auf einem Windows-Server (in dem Fall ein 2008 R2) mit IIS starteten die IIS-Dienste nicht, da der Windows-Prozessaktivierungsdienst mit folgender Fehlermeldung nicht starten wollte:

„Windows konnte den Prozessaktivierungsdienst nicht sarten – Fehler 6801: Die Transaktionsunterstützung im angegebenen Ressourcen-Manager wurde nicht gestartet oder aufgrund eines Fehlers heruntergefahren“

bzw.:

„Windows could not start the Windows Process Activation Service – Error 6801: Transaction support within the specified resource manager is not started or was shut down due to an error“

Das Problem kann man folgend lösen:

eine Eingabeaufforderung (cmd) als Administrator startet und folgenden Befehl ausführen:

fsutil resource setautoreset true c:\

Danach muss man den Server neu starten – jetzt sollte der WAS (Windows-Prozessaktivierungsdienst) wieder starten – und somit auch die davon abhängigen IIS-Dienste 🙂

Quelle: forum.iis.net

Das KB3159398, dass über Windows Update zur Zeit verteilt wird, ändert ein wenig die Art und Weise wie die Sicherheitsfilterung bei der Gruppenrichtlinienverarbeitung funktioniert.

Das kann zu Problemen führen, wie z.B.:

– Laufwerke werden nicht mehr gemappt
– Desktop-Symbole für Verknüpfungen werden nicht mehr sauber angezeigt
– Diverse Gruppenrichtlinien (z.B. Druckerzuweisungen, etc) funktionieren nicht mehr

Das Problem liegt an einem fehlendem Lese-Recht des Authentifizierte Benutzer (Authenticated Users) unter Delegierung, dass durch den Patch jetzt allerdings benötigt wird.

In dem KB dazu hat Microsoft das Problem auch beschrieben:

Known issues

MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the machines security context. This issue is applicable for the following KB articles:

3159398 MS16-072: Description of the security update for Group Policy: June 14, 2016
3163017 Cumulative update for Windows 10: June 14, 2016
3163018 Cumulative update for Windows 10 Version 1511 and Windows Server 2016 Technical Preview 4: June 14, 2016
3163016 Cumulative Update for Windows Server 2016 Technical Preview 5: June 14 2016

Symptoms

All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.

Cause

This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.

Resolution

To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:
– Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
– If you are using security filtering, add the Domain Computers group with read permission.

Lösung: Die Authentifizierten Benutzer manuell mit dem Lese-Recht bei den Delegierungen hinzufügen

AuthUsersGPO

Es gibt auch hier ein Script dass das automatisch macht.

Empfehlenswerter Artikel zu lesen: http://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/

Ich hatte in einem AD das Problem, dass nach einem Restore aus einem Snapshot die Domain Controllern die Anmeldung der User verweigerten und auch untereinander nicht mehr replizierten. Im Eventlog wurde folgender Fehler protokolliert:

Ereignistyp: Fehler
Ereignis Quelle: NTDS Allgemein
Ereigniskategorie: Steuerung
Ereignis-ID: 2103
Beschreibung: Die Active Directory-Datenbank wurde anhand eines Verfahrens nicht unterstützte Wiederherstellung wiederhergestellt. Active Directory können Benutzer anmelden, während das Problem weiterhin besteht. Als Ergebnis wurde der Netlogon-Dienst angehalten. Benutzer Aktion Siehe vorherige Ereignisprotokolle Einzelheiten. Weitere Informationen finden Sie im Hilfe- und Supportcenter unter http://support.microsoft.com.

Und bei der Replikation wurde die Fehlermeldung (z.B. bei repadmin /showrepl)

Der Quellserver nimmt keine Replikationsanforderung entgegen

ausgegeben.

Das ganze Problem wurde verursacht, dass durch die nicht unterstützte Wiederherstellung – in meinem Fall ein Snapshot – die Datenbank der Active Directorys auf Not Writeable gesetzt wurde.

Das ganze wieder ans laufen bekommt man wenn man in der Registry auf dem DC unter

HKLM\System\CurrentControlSet\Services\NTDS\Parameters

den Wert „Dsa Not Writable“ von 4 auf 0 setzt.

Dazu legt man noch einen REG_DWORD “Ignore USN Rollback” an und setzt den Wert auf 0

Danach muss man den Server neustarten.

Damit die Replikation wieder sauber funktioniert muss man auf allen DC-Servern die Befehle

repadmin /options “ServerName” -DISABLE_OUTBOUND_REPL
repadmin /options “ServerName” -DISABLE_INBOUND_REPL

ausführen – wobei „ServerName“ mit dem jeweiligen lokalen Servernamen des DCs ersetzten.

Jetzt sollte eigentlich alles laufen.

Falls allerdings die Replikation noch nicht funktioniert – oder andere Fehler im Eventlog protokolliert werden – kann noch ein Reset des Passwortes des Computerkontos der Domaincontroller nötig sein.

Das macht man auf den DCs folgendermaßen (am besten davor einen Reboot machen):

netdom resetpwd /server:anderer_dc /userd:domain\administrator /passwordd:*

Danach den Server rebooten.

Jetzt sollte es wirklich wieder laufen 🙂

Quelle: hyper-v-server.de

Ich hatte bei einem Exchange 2013 das Problem, dass Umlaute in Abwesenheitsnachrichten (Out of Office) bzw. Automatischen Antworten nicht dargestellt wurden – diese wurden mit einem ? ersetzt. Das sah dann so aus:

OOFUmlaute

Ich habe das Problem damit behoben, dass ich den ContentType der RemoteDomain auf dem Exchange von MimeText auf MimeHTMLText mittels der Exchange Management Shell umgestellt habe:

get-remotedomain | set-remotedomain -ContentType MimeHtmlText

Danach waren alle Umlaute in den Automatischen Antworten und Abwesenheitsnotizen (OOF halt 😉 ) wieder richtig

OOFUmlauteOOF

Quelle: TechNET

Nach der Installation von Exchange 2013 CU11 hatte ich das Problem, dass z.B. bei der Powershell-Abfrage Get-ExchangeServer nur noch alle alten Server mit Exchange 2010 angezeigt werden. Auch Server mit Exchange 2013 die noch keinen CU11 installiert hatten wurden nicht mehr angezeigt. Somit war die Exchange-Verwaltungsshell ziemlich nutzlos….

In der ECP (Exchange Administrative Center) auf dem Exchange 2013 mit CU11 jedoch wurden alle Server richtig angezeigt und man konnte auch Einstellungen, etc bearbeiten und auch ändern.

Um das Problem zu beheben und wieder muss folgendes ausgeführt werden:

1) Im Exchange Administrative Center das Postfach des Administrators auf den neuen Exchange 2013 CU11 verschieben

2) Auf dem Exchange 2013 CU11 in der Regisry unter HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ WSMAN\Client\ConnectionCookies die Einträge löschen (falls dort welche vorhanden sind)

Danach geht wieder alles in der Exchange-Verwaltungsshell 🙂

Quelle: TechNet

Die Rechte-Vererbung im ActiveDirectory ist manchmal bei bestimmten Benutzern deaktiviert – selten ist das gewollt – fast immer gibt es aber deswegen (vor allem in Verbindung mit Exchange) Probleme.

Einige Beispiele:

– ExchangeSynchronisationsfehler 86000C0A bei betroffenen Benutzern, obwohl OWA korrekt funktioniert

– Dateisystems-Auflistung im Explorer schlängt mit 0x86000Cxx Fehlern fehl

Fehler im Ereignisprotokoll von MSExchange ActiveSync mit dem Inhalt „Active directory Antwort: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0″.“

Exchange: das Verschieben der Mailbox der Benutzer (z.B. bei Exchange-Migrationen) schlägt fehl

Bei einem Benutzer kann man die Vererbung wie hier beschrieben ja manuell aktivieren – bei vielen Usern ist da ein automatisierter Weg zu empfehlen….

Das kann man ganz einfach mit der Powershell erledigen! Einfach die PowerShell ISE als Administrator ausführen und folgendes Script ausführen:

Import-Module activedirectory
$OU = "OU=INDIESEROUWERDENUSERGESUCHT,DC=MEINDOMAENE,DC=TLD"
$Users=get-aduser -Filter * -SearchBase $OU

if ($Users -ne $null) 
{

    foreach ($Entry in $Users) 
    {
    [string]$dn = (Get-ADUser $Entry).DistinguishedName
    $user = [ADSI]”LDAP://$dn”
    $acl = $user.objectSecurity
    Write-Host "Pruefe Benutzer:" (Get-ADUser $Entry).SamAccountName

        if ($acl.AreAccessRulesProtected)
        {
        Write-Host "Fixe Benutzer:" (Get-ADUser $Entry).SamAccountName
        $acl.SetAccessRuleProtection($false,$true)
        $inherited = $acl.AreAccessRulesProtected
        $user.commitchanges()
        }
    }

}

else 
{
    Write-Host "Keine Benutzer in $OU gefunden"
}

In der Zeile $OU = „OU=INDIESEROUWERDENUSERGESUCHT,DC=MEINDOMAENE,DC=TLD“ einfach die ensprechende OU angeben und alle Benutzer – auch in Unter-OUs – werden angepasst 🙂

Quelle: ugg.li