Nach dem Exchange 2013 SP1 wurde nun auch das Office 2013 SP1 frei gegeben.
Nachdem wir dies bei Microsoft schon intern testen konnten, hat es nun den finalen Stand erreicht und ist über Windows Update abrufbar.
Mehr Informationen oder auch den administrativen download findet ihr hier.
Das lang erwartete SP1 für Exchange 2013 wurde nun frei gegeben. Damit werden nun auch die Probleme mit der Kompatibilität zu Windows Server 2012 R2 Domain Controllern aus der Welt geschafft.
Für Exchange muss zwingend SP3 CU5 installiert sein. Die Supportability Matrix gibt hier genau Auskunft darüber.
Alle Infos zu dem Update im offiziellen Exchange Blog
Nun geht es auch Exchange 2003 an den Kragen. Der Support läuft am 8. April 2014 aus.
Es wäre daher Zeit auf Exchange 2010 zu migrieren- wie schon lange in diesem Artikel empfohlen: Time to Move from Exchange 2003
Wie uns das Lifecycle Formular nun auch bekannt gibt, läuft der Support am 8. April 2014 nun aus: Lifecycle
Durch die starken Architekturänderungen in RDS 2012 muss man sich beim Design einer neuen Farm Gedanken über die Clients machen die auf die Farm zugreifen.
Wir unterstützen mit Apps mittlerweile auch fremde Betriebsysteme wie diese aus dem Hause Apple prinzipiell:
Beim Server 2012 RDS geht der Zugriff immer über den Web Access Server. Ausserdem haben wir spezielle RDP Files- nachzulesen hier.
Dies bringt uns einige Beschränkungen mit:
Prinzipiell ist der Windows Embedded Client dem anderen vor zu ziehen. Dies nicht aus Gründen ob Windows oder Linux, sondern wegen dem Zertifikat. Wie hier in diesem Artikel beschrieben, arbeiten wir mit Zertifikaten in RDS. Falls wir dies aus einer internen CA beziehen, müssen wir einen Weg haben um diese auf den Linux Thin Client zu importieren. Dies aus dem Grund da der Linux Client nicht Domain Mitglied ist und daher auch die interne CA nicht als Root Zertifiezierungsstelle kennt.
Ich habe in diversen Artikeln über RDS erklärt dass nichts mehr ohne den Web Access Server geht- weil dieser der Einstiegspunkt für den Client ist:
Man könnte nun auf die Idee kommen und einfach eine RDP Verbindung direkt auf den Connection Broker herstellen, da dieser ja danach die Sessions an die Session Hosts weiter gibt. Theoretisch könnte dies funktionieren, tut es jedoch nicht. Wenn man dies versucht, und dann die RDP Verbindung aufbaut, wird einem folgende Fehlermeldung als Benutzer angezeigt:
Dies aus dem Grund da der Connection Broker die Session nicht weiterleitet, sondern versucht auf dem Connection Broker Server anzumelden, was für den "normalen" Benutzer folglich in einem Fehler enden wird.
Wieso ist dies so?
Um dies zu überprüfen, nehmen wir am einfachsten einen anderen Browser als den Internet Explorer und laden uns das RDP File vom Web Access Server nach dem Login auf der Webseite runter. Dieses RDP File öffnen wir nun mit einem Notepad und werden feststellen dass in dem File eine Fülle von Informationen sind:
In diesem RDP File geben wir die ganzen Farm, Connection Broker, Session Collection Informationen mit. Es wäre nun aber möglich auf jedem Client der mit RDP grösser Version 6 umgehen kann, dieses RDP File zu starten.