Hope This Helps

Problem:
Für mich hat sich die Frage gestellt, wie der Outlook-Client (gerade außerhalb der Organisation über Outlook Anywhere) den Autodiscover FQDN bekommt, die er anfragt um seine Autodiscover-Informationen zu bekommen.

Lösung:
Der Outlook-Client geht hier nach einem fest definierten Schema vor, dass man wissen sollte, da man sonst nicht versteht, warum der Client keine Autodiscover-Informationen erhält.

WICHTIG VORWEG: Als Mail-Domäne nimmt der Client nicht die Windows-Domäne sondern die Mail-Domäne der PRIMÄREN Mail-Adresse des Benutzers
Das kann Probleme machen, wenn man einem Benutzer nur eine interne Mailadresse gibt oder dieser verschiedene externe Mail-Adresse zugewiesen bekommen hat. Vor allem, wenn der Benutzer per Outlook Anywhere zugreift und keinen SCP erreichen kann und somit die Autodiscover-URLS abklappert.

Folgenden Ablauf durchläuft der Client für das Autodiscover-Ermittlung:
1.) Abfrage SCP (Service Connection Point) aus dem AD (ClientAccessServer AutodiscoverServiceInternalURI)
2.) Anfrage auf https://mail-domäne/autodiscover/autodiscover.xml
3.) Anfrage auf https://autodiscover.mail-domäne/autodiscover/autodiscover.xml
4.) Anfrage auf http://autodiscover.mail-domäne/autodiscover/autodiscover.xml
5.) Abfrage eines SRV-Records
6.) Verwendung der lokalen autodiscover.xml, soweit bereits vorhanden

Quelle: SebastianHetzel.net: Exchange Autodiscover

Problem:
Ich musste ein bereits migriertes Postfach vom Exchange 2013 auf den Exchange 2007 zurück verschieben.
Die Migrationsbatch wurde erzeugt, lief aber niemals los.

Lösung:
Aus mir leider nicht ganz verständlichen Gründen, muss man die erste Migration des Postfaches ZUM Exchange 2013 in der Migrationsübersicht löschen und danach ist eine Rückmigration problemlos möglich.
Sie können diese Löschen in der ECP-Website unter "Postfach" -> "Migration".
Hier die entsprechenden Batches des Postfaches suchen und alle löschen.
Nach der Löschung (kann etwas dauern - immer wieder aktualisieren) kann das Postfach auf den alten Exchange verschoben werden!

Problem:
Ich bin gerade bei einer Migration von Exchange 2007 auf Exchange 2013.
Da die Migration im laufenden Betrieb durchgeführt wird und Exchange 2013 nicht direkt auf die Öffentlichen Ordner von Exchange 2007 zugreifen kann, musste ich die Discovery-Mailbox-Variante wählen um den Zugriff der umgezogenen Clients zu ermöglichen (siehe Quelle unten).
Dabei ist aufgefallen, dass alle umgezogenen Benutzer auf Exchange 2013 mehrmals am Tag die Verbindung zum Öffentlichen Ordner auf Exchange 2007 verloren haben und sich ein Anmeldefenster dazu öffnet. Das war sehr lästig und ich habe viel an den IIS-Einstellungen vom alten und neuen Exchange versucht - alles erfolglos!
Daraufhin habe ich herausgefunden, dass ich Outlook über die Exchange-Proxy-Einstellungen zu einem TCP-Connect "zwingen" kann, indem ich dort den Haken "Bei schneller Verbindung zuerst über HTTP verbinden" entferne. Damit versucht Outlook erst eine TCP-Verbindung und dann eine HTTP-Verbindung. Das klappt super gut und die Verbindung zum alten Server geht über RPC/TCP und zum neuen über RPC/HTTP.
Das nächste Problem: Das Autodiscover überschreibt meine Einstellungen und setzt mir den Haken immer wieder neu!!!

Lösung:
Man kann mittels Registry eine Policy setzen, wodurch man die Einstellung dauerhaft festsetzen kann.
Hier die Policy, wie ich Sie aktuell für Outlook 2007 - 2013 erfolgreich einsetze:

Key : HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\xx.0\Outlook\RPC
Value Name : proxyserverflags
Value Type : REG_DWORD
Value : 39 (27h)

Wobei xx für die jeweilige Office-Version steht (12 = Office 2007, 14 = Office 2010, 15 = Office 2013, 16 = Office 2016)

Das ist zwar nicht die sauberste Lösung, da ich eigentlich das Problem am Exchange 2007 nicht gelöst habe doch will ich gerade nicht die Konfiguration des alten Servers so extrem abändern, dass mir etwas anderes "um die Ohren fliegt". Außerdem wird der alte Exchange-Server nach der Migration sowieso abgeschaltet und damit erledigt sich dann auch das Problem.

Quelle für Flags: getadmx.com: RPC/HTTP-Verbindungs-Flags

Quelle Discover Public Folder 2013: Technet: Konfigurieren älterer öffentlicher Ordner, wenn sich die Postfächer der Benutzer auf Exchange 2013-Servern befinden

Problem:
Meine User beschweren sich, dass bei Office 2013/2016 kein Office Picture Manager mehr dabei ist und dieser so komfortabel zu bedienen war.

Lösung:
Man kann den Microsoft Office Picture Manager kostenlos und ohne Lizenz-Probleme nachinstallieren.
Die Idee ist ganz einfach...der Picture Manager ist auch im Microsoft SharePoint Designer 2010 beinhaltet und dieser ist kostenlos im Internet erhältlich.

Folgende Vorgehensweise zur Installation des Picture Managers:
- Microsoft SharePoint Designer 2010 herunterladen (32-Bit-Version): Microsoft SharePoint Designer 2010 (32-Bit)
- Installation angepasst durchführen und alle Punkte deaktivieren außer dem Office Picture Manager


Nach der Installation steht der Picture Manager zur Verfügung. Sollte ein Lizenz-Audit von Microsoft stattfinden, wird nur der SharePoint-Designer ausgelesen und dieser ist kostenlos erhältlich.
Ich weiß, dass die Installationsroutine ca. 400 MB umfasst, aber was tut man nicht für das Wohl seiner User!

Quelle:
IT-Logbuch: Microsoft Picture Manager kostenlos nachinstallieren

Problem:
Ich ziehe gerade unseren Exchange 2007 auf den Exchange 2013 um. Dabei muss ich auch die Transport-Regeln wie z.B. Disclaimer und Weiterleitungen migrieren. Im ersten Augenblick dachte ich, die Übernahme muss manuell erfolgen, was einen nicht unerheblichen Zeitaufwand bedeutet hätte - alleine die Disclaimer mit allen Formatierungen wären viel Arbeit gewesen.

Lösung:
Man kann die Transport-Regeln aus dem alten Exchange 2007 exportieren und in den Exchange 2013 importieren.
Folgende Vorgehensweise hierzu:

Exchange 2007
Öffnen Sie die Powershell auf dem alten Exchange 2007 und führen Sie folgenden Befehl für dne Export aus:

Export-TransportRuleCollection -FileName "C:\ExportedRules.xml"

Danach finden Sie eine Datei ExportedRules.xml unter C:\ vor. Diese kopieren Sie auf den Exchange 2013!

Exchange 2013
Vergewissern Sie sich, dass die Datei ExportedRules.xml auf dem Exchange 2013 vorliegt.
Öffnen Sie die Powershell und führen Sie folgende Befehle für den Import der Transport-Regeln durch:

[Byte[]]$Data = Get-Content -Path "C:\ExportedRules.xml" -Encoding Byte -ReadCount 0 
 Import-TransportRuleCollection -FileData $Data

Danach können Sie in der Exchange-Verwaltungswebsite prüfen, ob unter "Nachrichtenfluss" -> "Regeln" alle Transport-Regeln erfolgreich übernommen wurden. Prüfen Sie bitte auch die Funktionsfähigkeit der Regeln.
Bei mir hat das problemlos funktioniert!

Quelle:
MS Technet: Part 2: Step-by-Step Exchange 2007 to 2013 Migration
Microsoft: You cannot migrate transport rules from Exchange Server 2007 to Exchange Server 2013

Problem:
Ich hatte eine RDP-Session, die sich "verrannt" hat und ich konnte auch keinen weiteren Benutzer mehr anmelden.
Stattdessen lese ich folgende Meldung beim Anmeldebildschirm:

"Der angeforderte Vorgang konnte nicht ausgeführt werden, da die Remotedesktopdienste derzeit ausgelastet sind. Versuchen Sie es in einigen Minuten noch einmal. Andere Benutzer können sich normalerweise weiterhin anmelden."

Die Anmeldung mit einem anderen Benutzer ist ebenfalls nicht möglich.
Wie komme ich jetzt an den Server um die Session zurückzusetzen?

Lösung:
Man kann von einem anderen Server/Client aus die Session per Kommandozeile ermitteln und zurücksetzen.
WICHTIG: SIE BENÖTIGEN EINEN BENUTZER, DER ADMINISTRATOR-RECHTE AUF DEM BETROFFENEN SERVER HAT!

1.) Melden Sie sich mit dem administrativen Benutzer an einem anderen Server/Client an

2.) Führen Sie den Befehl "query session /server:" aus, wobei Sie für den Namen des betroffenen Servers eintragen.

3.) In der Ausgabe sollten sie die betroffene Session sehen - merken Sie sich die entsprechende SESSION-ID

5.) Nun setzen Sie die betroffene RDP-Sitzung mit folgendem Befehl zurück: "reset session >SESSION-ID> /server:"
Wobei die Session-ID und der Servername mit den jeweiligen richtigen Werten ersetzt werden müssen.

6.) FERTIG - Die Session wird nun zurückgesetzt - das kann einige Minuten dauern!

Sollte der Fehler häufiger auf Server 2008R2 auftreten, dann gibt es von Microsoft einen Hotfix.
Hier scheint es ein Problem zu geben zwischen dem Prozess csrss.exe und manchen Anwendungen.
Microsoft: KB2661332 - Sie können keine Remotedesktopdienste-Sitzung auf einem Windows Server 2008 R2-basierten Server wiederherstellen.

Quelle:
rodolfovaraujo: How to kill RDP sessions remotely