Veröffentlichung des Originalartikels: 13.10.2011

Willkommen bei Teil 2 aus der Blogreihe zum Verwalten Ihrer Office-Objekte in einer Tablet-Umgebung. In Teil 1 habe ich in erster Linie die wichtigsten Methoden für die Verwendung von Office mit Rich-Clients, Remote-Rich-Clients, Office für Mac, Web Apps und Office auf dem Mobiltelefon vorgestellt. Nun möchte ich mich mit den Technologien befassen, um sicherzustellen, dass E-Mail, Kalender und sonstige Office-Inhalte auf mehreren Gerätetypen verwendet werden können. Ich stelle mir „Office“ neben den Apps selbst als Arbeitsauslastung in Form von Kommunikation, E-Mail und Zusammenarbeit vor, weshalb diese Arbeitsauslastungen in diesem Beitrag unbedingt behandelt werden müssen. Bevor ich mich mit Themen wie der Anpassung der Office-Benutzeroberfläche für Touchscreen-Geräte oder dem Remotezugriff auf Desktops befasse, beginnen wir mit der von mir verwendeten Buildumgebung. Anschließend geht es um die Grundlagen der Konnektivität von mobilen Geräten bei Office-Arbeitsauslastungen.

Meine Buildumgebung

Ich bin ein Pedant und möchte immer sicherstellen, dass alles ordnungsgemäß ausgeführt wird, bevor ich etwas zu beschreiben versuche. Ich habe zwar nicht die komplette Windows Server System Reference Architecture (WSSRA)-Umgebung (die wir liebevoll als „Minicore“ bezeichneten) für die Tests verwendet, aber eine relativ leistungsfähige (und portable) Umgebung. Minicore in WSSRA bestand aus 32 virtuellen Computern. Ich verfüge jedoch über sechs virtuelle Computer und verwende den Host, ein iPad und Samsung Galaxy Tab als Clients.

  • HP8540W-Laptop mit Quad-Core i7, 16 GB RAM und 1 TB RAID 0 SSD-Speicher. Integrierte Netzwerkschnittstellenkarte (Network Interface Card, NIC) und PCIE-Netzwerkschnittstellenkarte
  • Windows Server 2008 R2 Enterprise mit installierter Rolle für Hyper-V
  • Sechs virtuelle Computer unter Windows Server 2008 R2 Standard
    • Domänencontroller
    • SharePoint 2010
    • Exchange Server 2010
    • RemoteApp für Remotedesktopdienste
    • Citrix XenApp
    • Forefront Unified Access Gateway 2010 (UAG)
  • iPad 2 (mit iOS 4)
  • Samsung Galaxy Tab (mit Android 2.2)
  • MacBook Air mit Office für Mac 2011
  • Cisco-Funkrouter verbunden mit der PCIE-Netzwerkschnittstellenkarte

Das waren meine Mitbringsel zur TechEd und zur SharePoint-Konferenz dieses Jahr, weshalb Sie sich beim Sicherheitscheck am Flughafen nicht unbedingt hinter mir in der Warteschlange befinden sollten. Mit dieser Umgebung werde ich auch die Screenshots für die restlichen Beiträge in dieser Reihe erstellen. Beginnen wir also mit den Grundlagen.

Exchange ActiveSync

Im Jahr 2002 erstellten wir AirSync als Bestandteil von Microsoft Information Server (MIS) 2002, und etwa ein Jahr später wurde dieses Feature erweitert und in Exchange Server 2003 integriert und in Exchange ActiveSync umbenannt. Ich erinnere mich noch an die Möglichkeit, zu Beginn meiner Zeit bei Microsoft E-Mail und Kalender auf meinem Mobiltelefon zu nutzen, was für mich ein Lebensretter war. Im Laufe der Jahre wurde Exchange ActiveSync (EAS) weiterentwickelt und durch die Verfügbarkeit für andere als Windows-Plattformen eine zentrale Komponente und ein Sicherheitspfeiler für viele Gerätetypen, einschließlich Windows Mobile und Windows Phone, iPad und iPhone von Apple sowie Android-basierter Geräte. Für mich ist dies im Rahmen dieser Blogreihe auch der kleinste gemeinsame Nenner für den Zugriff auf Office auf einer Reihe von Geräten.

Exchange ActiveSync bietet eine Reihe wichtiger administrativer IT-Features, wie beispielsweise die Möglichkeit, eine PIN zum Entsperren eines Geräts anzufordern und zu erzwingen. Dadurch wird ein zusätzlicher Authentifizierungsfaktor erzwungen, sodass man beim Verlust eines Geräts die PIN für den Zugriff entweder auf das komplette Gerät – bei Geräten mit systemeigener Exchange ActiveSync-Unterstützung – oder auf die Softwareumgebung, mit der eine Verbindung mit EAS hergestellt wird, wie z. B. TouchDown von NitroDesk oder RoadSync von DataViz, kennen muss.


Im obigen Screenshot ist die Eigenschaftenansicht von Exchange Server 2010 abgebildet, und neben Kennwortrichtlinien können wir Richtlinien für Synchronisierungseinstellungen und sonstige Geräteattribute, wie z. B. die Möglichkeit der Deaktivierung von Gerätekameras und Browsern, festlegen. In Hochsicherheitsumgebungen bieten diese Steuerelemente zusätzlichen Schutz vor Datenlecks sowie Schutz vor dem Einschleusen von bösartigem Code über Webbrowser. Apple stellt darüber hinaus das iPhone-Konfigurationsprogramm bereit, das für die Verwendung mit Infrastruktur für die mobile Geräteverwaltung von Drittanbietern vorgesehen ist, um Richtlinien an iPhone- und iPad-Geräte zu übertragen.

Ein wesentlicher Bestandteil der Unternehmenssicherheit für diese Geräte ergibt sich aus den Exchange ActiveSync-Funktionen und dem erforderlichen Arbeitsaufwand, damit sie von diesen Geräten unterstützt werden. Dies gilt auch für Geräte mit Android 2.0 und neuere Geräte mit systemeigener EAS-Unterstützung.

Die Konfigurierbarkeit von Geräten mithilfe der Steuerelemente in Exchange ActiveSync ist für die meisten Geräte ein Schritt in die richtige Richtung, und durch die Beschränkung der Anzahl von Tagen, die E-Mail auf einem Gerät gespeichert wird, wird das Risiko im Zusammenhang mit der Datensicherheit reduziert. Die Implementierung von EAS auf Geräten, einschließlich iOS, Android, Symbian und Windows Phone, variiert zwischen den Plattformen jedoch erheblich. Dies gilt insbesondere für die Verwaltung von Informationsrechten (Information Rights Management, IRM) unter Verwendung von Exchange ActiveSync. Zu dem Zeitpunkt, als ich diesen Beitrag verfasst habe, war die Verwaltung von Informationsrechten unter Verwendung von EAS auf Windows Phone- und Windows Mobile-Plattformen beschränkt. Für Organisationen, die eine höhere Sicherheit für bestimmten E-Mail-Datenverkehr benötigen, bietet die Verwaltung von Informationsrechten kontinuierlichen Schutz für Messaginginhalte. EAS-Clients werden verstärkt für den Zugriff auf E-Mail verwendet, weshalb die Benutzer von Mobilgeräten unbedingt in der Lage sein müssen, durch die Verwaltung von Informationsrechten geschützte Inhalte auf sichere Weise zu erstellen und zu verwenden. Mit meiner Aussage, dass die EAS-Unterstützung auf diesen Geräten ein Schritt in die richtige Richtung ist, meine ich, dass dies nicht mit Active Directory-Gruppenrichtlinien-Steuerelementen vergleichbar ist, die den meisten IT-Abteilungen vertraut sind. Dies sollte berücksichtigt werden, falls Sie sich mit dem Gedanken tragen, die Benutzer auf nicht so weit entwickelte Plattformen umzustellen.

Gruppenrichtlinien-Konfigurationsverwaltung mit Office

Office kann auf eine lange Entwicklung der granularen Konfigurationsverwaltung auf der Windows-Plattform zurückblicken. Ausgehend von den Richtlinienverwaltungsfunktionen in der Version Office 97 wurden die Funktionen so etwa in den letzten 15 Jahren drastisch erweitert. Damals gab es kaum mehr als 50 erzwingbare Einstellungen. In Office 2010 gibt es dagegen über 2.000 erzwingbare Einstellungen. Office für Mac 2011 (ebenso wie bei vorherigen Mac-Versionen) enthält übrigens keine erzwingbaren Einstellungen und verwendet nur optionale Einstellungen zum Installationszeitpunkt, wobei dieses Verhalten von den Benutzern auf Wunsch geändert werden kann (siehe Teil 1). Die Einstellungen zum Installationszeitpunkt bringen mich auf die Möglichkeiten, wie Office zum Installationszeitpunkt unter Windows konfiguriert werden kann. Diese spielen eine wichtige Rolle für die Sicherheit und Verwaltbarkeit von Office, da Sie nicht nur die Konfiguration von Office festlegen können, sondern auch Dinge wie Vertraulichkeitseinstellungen (Regeln für die Verschlüsselung und die Verwaltung von Informationsrechten), Integritätseinstellungen (Regeln für vertrauenswürdige Herausgeber und Speicherorte sowie digitale Signaturen) und Verfügbarkeitseinstellungen (VBA-Makro-, Add-In-, ActiveX-, Internet Explorer- und Dateiblockierungsregeln) konfigurieren können. Diese Kontrollmöglichkeiten gibt es nur für eine Windows-Umgebung mit Office.

Es gibt drei primäre Kontrollmechanismen, um die Verwendung von Office auf einem Computer unter Windows anzupassen:

  1. Vordefinierte Einstellungen der Gruppenrichtlinien
  2. Config.xml
  3. Mit dem Office-Anpassungstool (OAT) generierte benutzerdefinierte MSP-Datei

Diese Mechanismen sind in der Reihenfolge aufgeführt, in der sie im Falle von Konflikten gewinnen. Erwartungsgemäß haben Gruppenrichtlinieneinstellungen die meiste Kontrolle und haben Vorrang vor Definitionen in der Datei config.xml, die wiederum Vorrang vor den Definitionen in einer mit dem Office-Anpassungstool (OAT) generierten benutzerdefinierten MSP-Datei haben. Beim Konfigurieren von Office 2010 sind Tausende möglicher Gruppenrichtlinieneinstellungen verfügbar. Das Problem besteht darin, wo man beginnen sollte. Es gibt den Microsoft-Manager für Sicherheitskonformität zur Unterstützung beim Einrichten von Basiseinstellungen, da es einfacher ist mit einer bekannten verwendbaren Konfiguration zu beginnen und diese anzupassen, anstatt ganz von vorne zu beginnen.

Die nächste Priorität gehört der Datei config.xml, die zusammen mit Office verwendet wird. Da es sich um eine XML-Datei handelt und nicht allzu viel vordefiniert ist, werden Sie diese Datei wahrscheinlich nicht für eine lange Liste von Einstellungen verwenden möchten, sondern beispielsweise zum Konfigurieren einfacher Aufrufe eines Aktivierungsdiensts oder zum Anpassen von Sprachkorrekturtools. In diesen Fällen ist die Datei config.xml die optimale und manchmal einzige Option. Eine relativ standardmäßige Datei config.xml sieht wie folgt aus:

Die letzte Option ist die Verwendung des Office-Anpassungstools (OAT). Mit diesem Tool wird im Prinzip festgelegt, wie Office installiert und konfiguriert wird. Diese Einstellungen werden – wie bei der Datei config.xml – nur zum Installationszeitpunkt festgelegt und werden nicht erzwungen. Wenn Sie dann keine Gruppenrichtlinien erzwingen, ist die Verwaltbarkeit und Sicherheit dessen, wofür in der Umgebung Richtlinien erzwungen werden müssen, ernsthaft gefährdet, ähnlich wie dies bei Office für Mac der Fall ist. Das OAT weist die gleichen Einstellungen wie die Gruppenrichtlinien auf und ermöglicht das Schreiben der Registrierung sowie das Ausführen benutzerdefinierter Befehle während des Office-Setupprozesses. Die in einer verwalteten Bereitstellung von Office 2010 häufigste Kontrollmöglichkeit ist wahrscheinlich die Einstellung Dialogfeld "Empfohlene Einstellungen" unterdrücken (Suppress recommended settings dialog). Denn dadurch wird den Benutzern eine Meldung angezeigt, ob Windows Update verwendet werden soll, was die meisten IT-Administratoren von verwalteten Umgebungen im Namen des Benutzers mit Tools wie Windows Server Update Services (WSUS) oder System Center Configuration Manager ausführen würden.

Dies sind die wichtigsten Methoden, um eine Office-Installation unter Windows anzupassen. Ich wollte dieses Thema unbedingt behandeln. Denn selbst wenn Sie diesen Blog nur wegen Hinweisen zur Bereitstellung von Office auf einem iPad lesen, spielen diese Methoden eine Rolle, wenn wir uns mit den Methoden zum Hosten von Office auf einem Remotedesktop oder einem Server und dem Zugriff darauf per iPad, Android- oder Windows-Gerät beschäftigen. Unabhängig davon, ob ich auf einem Computer unter Windows Server 2008 R2 mit installierter Remotedesktopdienste-Rolle oder auf einem Remotecomputer unter Windows 7 bereitstelle, möchte ich dennoch die Möglichkeit haben, diese Installation dynamisch anzupassen – insbesondere bei der Bereitstellung dieses Diensts für Tausende von Benutzern.

Und damit beende ich Teil 2 dieser Blogreihe. Lesen Sie unbedingt auch Teil 1. Und ich hoffe, Teil 3 in den nächsten Tagen zu veröffentlichen.

Vielen Dank, dass Sie diesen Beitrag gelesen haben.

Jeremy Chapman

Senior Product Manager

Office IT Pro Team

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Windows, iPad and Android – Managing and Using Your Office Assets in a Tablet World (Part 2)