Ein Blick auf die neuen APIs und das Verteilen von Apps

Windows 8.1 goes Enterprise
Kommentare

Viele Unternehmen haben erst kürzlich auf Windows 7 umgestellt, womit Windows 8.1 für sie noch kein Thema ist. Doch auch in Unternehmen mit Windows-7-Landschaften ist es durchaus denkbar, dass neben den vorhandenen Windows-7-Geräten zusätzliche Windows-8.1-Geräte angeschafft werden, z. B. um das Management mit Tablets auszustatten, die optimal auf die Microsoft-Infrastruktur abgestimmt sind. Und spätestens dann sollten IT-Architekten und Entwickler wissen, welche Möglichkeiten Windows-Store-Apps unter Windows 8.1 bieten und wie sie verteilt werden. Dieser Artikel gibt einen Einblick.

„Windows-Store-Apps sind hauptsächlich für den Consumer-Markt“ – davon waren viele Unternehmen mit dem Erscheinen von Windows 8 überzeugt. Microsoft macht nach wie vor einen großen Teil des eigenen Umsatzes mit Enterprise-Kunden, doch bei Unternehmen ist heute meist noch Windows 7 oder sogar eine ältere Version im Einsatz. Und Windows 7 ist tatsächlich ein sehr stabiles Betriebssystem, womit es keine akuten Gründe für eine komplette Migration auf Windows 8.1 gibt. Zudem wurde an Windows 8 Einiges kritisiert: fehlender Startbutton, kein klassisches Startmenü, kein Booten in den Desktop, Modern UI und klassicher Desktop fühlen sich wie zwei verschiedene Systeme an etc. Diese Punkte wurden mit Windows 8.1 zwar nicht komplett behoben, jedoch gibt es einige Verbesserungen, auch von Drittanbietern, die hier weiterhelfen.

Auch die Windows-Store-Apps wurden in Windows 8 kritisiert: Typische Business-Controls wie z. B. ein DatePicker fehlen und müssen über Dritthersteller bezogen werden. Apps können lediglich ein einziges Fenster haben, mehr als zwei Apps lassen sich nicht gleichzeitig auf dem Bildschirm darstellen, das Data Binding hinkt jenem der WPF weit hinterher und so weiter.

Mit Windows 8.1 hat Microsoft nachgebessert und zudem zahlreiche neue WinRT-APIs eingeführt. Darunter befinden sich neue Controls, Erweiterungen im Data Binding und vieles mehr. Dieser Artikel zeigt die wichtigsten Neuerungen, bevor auf das Verteilen von Apps und auf weitere Windows-8.1-Enterprise-Möglichkeiten eingegangen wird, bei denen es darum geht, das Startmenü zurückzubringen und das Modern UI besser mit dem Desktop zu verbinden.

Neue Controls

Windows 8.1 enthält viele neue Controls: Hub, Flyout, MenuFlyout, SettingsFlyout, Hyperlink, CommandBar, neue AppBar-Controls sowie DatePicker und TimePicker. Sicherlich zeigt jede Business-App an mindestens einer Stelle ein Datum an. Daher ist ein DatePicker sehr hilfreich. Entwickler mit Erfahrung in anderen XAML-basierten Frameworks wie Silverlight wissen, dass auch dort der DatePicker nicht in der ersten Version verfügbar war. Der neue DatePicker der WinRT verfügt über eingebaute Lokalisierungsfunktionen und diverse Einstellungsmöglichkeiten. Mit der Date Property (Typ: DateTimeOffset) wird das eigentliche Datum gesetzt oder ausgelesen. Passend dazu gibt es ein DateChanged-Event, das bei einer Änderung über die Event-Argumente das alte und neue Datum liefert. Mit den Properties DayFormat, MonthFormat und YearFormat lässt sich das Format von Tag, Monat und Jahr bestimmen. Alle Properties sind vom Typ String. Visual Studios Intellisense listet die verfügbaren Formatierungen beim Setzen einer dieser Properties im XAML-Editor zur Auswahl auf (Abb. 1). Damit müssen sich Entwickler nicht allzu viel Gedanken über die verfügbaren Formatierungen machen.

Abb. 1: Visual Studio unterstützt den Entwickler beim Wählen des Formats

Zur Demonstration der Formatierungen werden in Listing 1 vier einfache DatePicker definiert. Die Header Property bestimmt dabei ein kleines Label, das über dem DatePicker angezeigt wird. Die Properties DayFormat, MonthFormat und YearFormat enthalten für jeden definierten DatePicker verschiedene Werte. Beachten Sie, dass die Formatierungen immer mit einem leeren geschweiften Klammerpaar beginnen („{}“). Dies ist notwendig, da der XAML-Parser ansonsten z. B. beim Wert {day.integer(2)} nach einer Markup Extension namens day suchen würde, die jedoch nicht existiert. Die Auswirkungen der in Listing 1 definierten Formatierungen sind in Abbildung 2 zu sehen. Beachten Sie hier, dass jeder DatePicker in Form von drei ComboBox-Elementen dargestellt wird. Die einzelnen ComboBox-Elemente lassen sich über die Properties DayVisible, MonthVisible und YearVisible ein- bzw. ausblenden.


  
  
  
  

Abb. 2: Der DatePicker besteht aus drei ComboBox-Elementen

Neben diesen Funktionen lässt sich über die CalendarIdentifier Property der gewählte Kalender einstellen. Es gibt Werte von gregorianisch über hebräisch bis hin zu japanisch. Über die Properties MinYear und MaxYear wird die Auswahl des Jahres eingeschränkt und via Orientation Property die Ausrichtung des DatePickers entweder horizontal (Default) oder vertikal festgelegt. Unterm Strich ist der DatePicker also ein sehr brauchbares Control zum Anzeigen und Bearbeiten von Datumswerten in Business-Apps. Neben dem DatePicker enthält die WinRT in Windows 8.1 noch den TimePicker, der vom Prinzip her gleich aufgebaut ist und, wie der Name schon sagt, zum Editieren von Zeiten gedacht ist.

Microsoft hat mit Windows 8.1 aber nicht nur neue Controls hinzugefügt, sondern auch bestehende aufgepeppt. So besitzen die Controls zum Editieren von Daten allesamt eine Header Property. Damit lassen sich Eingabefelder einfach beschriften, ohne dass in XAML explizit ein zusätzliches Label zum eigentlichen Eingabe-Control zu erstellen ist. Neben der Header Property haben einige Controls wie TextBox, ComboBox und DatePicker auch eine PlaceholderText Property. Darüber lassen sich diese Controls mit einem einfachen Wasserzeichen ausstatten. Lsting 2 zeigt zwei TextBox-Elemente und eine ComboBox. Auf allen drei Objekten sind die Properties Header und PlaceholderText gesetzt.


  
  
  
    weiblich
    männlich
  

Abbildung 3 zeigt die Elemente aus Listing 2. Jedes Element ist aufgrund der gesetzten Header Property mit einem kleinen Label gekennzeichnet. Darüber hinaus verfügt jedes Element über einen Wasserzeichentext. Wird in eine TextBox etwas eingegeben, verschwindet der PlaceholderText. Sobald der eingegebene Wert wieder entfernt wird, erscheint erneut der in der PlaceholderText Property definierte Wert. Gleich verhält es sich mit anderen Eingabe-Controls wie z. B. der ComboBox oder dem DatePicker.

Abb. 3: Die Properties „Header“ und „PlaceholderText“ in Aktion

[ header = Seite 2: App-Darstellungen ]

App-Darstellungen

Viele Unternehmen, genauso wie viele Benutzer aus dem Consumer-Bereich empfanden das Positionieren von Windows-Store-Apps auf dem Bildschirm unter Windows 8.0 als sehr einschränkend. Windows-Store-Apps konnten unter Windows 8.0 nämlich nur vier Zustände FullScreenLandscape, FullScreenPortrait, Snapped und Filled einnehmen. Mit Windows 8.1 hat Microsoft diese Einschränkungen aufgehoben. Windows-Store-Apps können nun eine flexible Breite haben. So lassen sich beispielsweise zwei Apps in der Splitansicht gleich breit auf einem Bildschirm darstellen. Außerdem lassen sich jetzt mehr als zwei Apps auf einem Bildschirm anzeigen, was insbesondere für Unternehmen wichtig ist, die Windows 8.1 nicht nur auf Tablets, sondern eben auch auf Desktoprechnern mit größeren Bildschirmen einsetzen möchten.

Die Breite einer App muss in Windows 8.1 mindestens 500 Pixel betragen. Die Snapped-Ansicht aus Windows 8.0 war jedoch lediglich 320 Pixel breit. Falls es für eine App unter Windows 8.1 Sinn macht, auch diese sehr schmale Ansicht anzubieten, muss dies im Package.appxmanifest speziell aktiviert werden (Abb. 4).

Abb. 4: Die Mindestbreite von 320 Pixeln lässt sich im „Package.appxmanifest“ aktivieren

Mehrere Fenster

In Windows 8.0 konnte eine Windows-Store-App lediglich ein Fenster besitzen. Mit Windows 8.1 wurde diese Einschränkung nun aufgehoben und aus einer Windows-Store-App heraus lassen sich jetzt beliebige weitere Fenster öffnen. Dieses Feature nutzt beispielsweise die Mail-App in Windows 8.1. Über die AppBar (Abb. 5) oder die Tastenkombination STRG + O lässt sich eine E-Mail auch in einem neuen Fenster öffnen.

Abb. 5: Die AppBar der Mail-App erlaubt das Öffnen im neuen Fenster

Um in der eigenen App eine bestimmte Page in einem neuen Fenster zu öffnen, wird zunächst der Dispatcher für das neue Fenster benötigt. Dazu wird in der App.xaml.cs-Datei die OnWindowCreated-Methode der Application-Klasse überschrieben und darin die ebenfalls erstellte statische Property NewWindowDispatcher auf den CoreDispatcher des neu erzeugten Window-Objekts gesetzt (Listing 3). Damit sind die Grundsteine gelegt.

sealed partial class App : Application
{
  ...
  public static CoreDispatcher NewWindowDispatcher { get; set; }
  protected override void OnWindowCreated(WindowCreatedEventArgs args)
  {
    base.OnWindowCreated(args);
    NewWindowDispatcher = args.Window.Dispatcher;
  }
}

Mit dem gespeicherten CoreDispatcher lässt sich eine neue Page jetzt recht einfach in einem eigenen Fenster öffnen. Zuerst wird die CreateNewView-Methode der CoreApplication-Klasse aufgerufen (Listing 4). Diese führt dazu, dass die in der App-Klasse überschriebene OnWindowCreated-Methode aus Listing 3 aufgerufen wird. Die NewWindowDispatcher Property in der App-Klasse wird darin gesetzt, womit sie in Listing 4 wiederum verwendet werden kann, um für das neue CoreWindow einen Frame zu erstellen und diesen zur gewünschten Page zu navigieren. In Listing 4 ist die gewünschte Page die PageToOpenInNewWindow.

Um das neue Fenster auch anzuzeigen, wird die statische TryShowAsStandaloneAsync-Methode der ApplicationViewSwitcher-Klasse aufgerufen. Über den zweiten Parameter vom Typ der Aufzählung ViewSizePreference lässt sich auch bestimmen, mit welcher Größe das zweite Fenster angezeigt werden soll. In unserem Beispiel wurde der Wert UseHalf gewählt, womit das Originalfenster und das zweite Fenster in einer Splitansicht angezeigt werden.

private async void Button_Click(object sender, RoutedEventArgs e)
{
  CoreApplicationView view = CoreApplication.CreateNewView("", "");
  int viewId = 0;
  await App.NewWindowDispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
    {
      viewId = ApplicationView.GetApplicationViewIdForWindow(view.CoreWindow);

      var frame = new Frame();
      frame.Navigate(typeof(PageToOpenInNewWindow));
      Window.Current.Content = frame;


  });
  await ApplicationViewSwitcher.TryShowAsStandaloneAsync(viewId, ViewSizePreference.UseHalf);
}

Zugriff auf Daten

Windows-Store-Apps können nicht direkt mit einer Datenbank kommunizieren, die ADO.NET-Funktionen sind in der WinRT nicht enthalten. Stattdessen läuft die Kommunikation mit einer Datenbank stets über einen Service ab. Oft werden dafür REST-basierte Services verwendet, da sie sich von x-beliebigen Clients einfach anbinden lassen.

Damit sich Windows-Store-Apps im eigenen Unternehmen mit Daten versorgen lassen, gilt eine gute Architektur als Grundlage. Nur wer in der Lage ist, Daten und Geschäftslogik plattformübergreifend bereitzustellen, kann auf einfache Weise weitere Systeme wie Windows 8.1, iOS oder Android ins Unternehmen einbinden. Abbildung 6 zeigt eine klassische Architektur. Die Windows-Store-App kann die Daten einfach vom Service laden und dem Benutzer präsentieren.

Abb. 6: Typische Architektur zur Einbindung diverser Plattformen

[ header = Seite 3: Data Binding ]

Data Binding

Sind die Daten geladen, kommt das Data Binding ins Spiel. Das der WinRT hinkt jenem der WPF und auch jenem von Silverlight leider noch etwas hinterher. Der Hauptgrund dafür liegt darin, dass Microsoft die komplette Binding Engine für die WinRT von Null auf in nativem Code neu implementieren musste. Wenn bestimmte Features fehlen, dann hauptsächlich aus Zeitgründen.

In Windows 8.1 wurde das Binding bereits etwas erweitert. So kann die UpdateSourceTrigger Property nun auch den aus der WPF bekannten Wert PropertyChanged enthalten. Mit diesem Wert aktualisiert z. B. eine gebundene TextBox die Quelle nicht erst beim Verlieren des Fokus, sondern bei jeder Änderung. In bestimmten Szenarien ist das durchaus sinnvoll.

Ebenfalls neu sind die beiden Properties FallbackValue und TargetNullValue. Mit der FallbackValue Property lässt sich ein Wert definieren, der zurückgegeben wird, wenn die Binding Engine keinen eigenen Wert ermitteln konnte. Dies ist der Fall, wenn der gebundene Pfad nicht existiert. Mit der TargetNullValue Property lässt sich ein Wert definieren, der verwendet wird, wenn die Binding Engine einen Null-Wert zurückgibt. Neben diesen Änderungen erlaubt die WinRT jetzt auch den Zugriff auf die bei einem Binding unter der Haube verwendete BindingExpression. Darüber lassen sich Ziel und Quelle eines Bindings manuell aktualisieren.

Das Validieren von Eingabedaten wird jedoch nach wie vor nicht unterstützt. Dies ist insbesondere bei Unternehmens-Apps einer der zentralen Punkte. Leider werden die dafür notwendigen, aus der WPF bekannten Interfaces IDataErrorInfo und INotifyDataErrorInfo noch nicht unterstützt. Das Interface INotifyDataErrorInfo ist zwar bereits in der WinRT enthalten, wird von der Binding Engine jedoch nicht verwendet.

Fehlende Features

Das im vorigen Abschnitt erwähnte Validieren von Daten ist ein von Unternehmen oft genanntes Argument dafür, dass sich Windows-Store-Apps nicht für den Enterprise-Bereich eignen. Allerdings lässt sich eine Validierung recht einfach manuell implementieren. Wer es nicht von Hand erledigen möchte, kann auf Prism für Windows-Store-Apps zurückgreifen. Prism ist eine zusätzliche Bibliothek, die von Microsofts patterns-&-practices-Team entwickelt wurde. Sie ist bereits aus der WPF bekannt und bringt für Windows-Store-Apps verschiedenste Funktionen mit: MVVM, Validierung, lose Kopplung, Event-Aggregation u.v.m.

Für die Validierung müssen zu validierende Objekte von der Prism-Klasse ValidatableBindableBase ableiten. Auf Properties lassen sich dann typische Attribute wie Required oder RegularExpression setzen. Die Validierungsfehler lassen sich im UI an einer zentralen Stelle anzeigen. Damit auch die Eingabe-Controls bei einem Validierungsfehler entsprechend markiert werden, bringt Prism das eigene HighlightFormFieldOnErrors Behavior mit. Wird z. B. eine TextBox mit diesem Behavior ausgestattet, wird sie rot umrandet, wenn ein entsprechender Validierungsfehler der gebundenen Property vorliegt.

Für weitere Informationen zur separaten Prism-Bibliothek und insbesondere der darin enthaltenen Validierung lohnt sich ein Blick in die Dokumentation, die auf MSDN verfügbar ist.

Neben der Validierung vermissen einige Unternehmen auch ein DataGrid, auf der anderen Seite sehen viele ein DataGrid für die Touch-Bedienung nicht geeignet. Hier scheiden sich die Geister. Allerdings gibt es durchaus Szenarien, in denen ein DataGrid Sinn macht. Beispielsweise wenn die App auch am großen 27-Zoll-Monitor ohne Touch, aber mit Maus und Tastatur verwendet werden soll. Und diese Art der Bedienung ist heute noch in sehr vielen Unternehmen der Standard. Möchte man also dafür ein DataGrid verwenden, bleibt wieder nur ein Dritthersteller. Das bringt eine weitere Abhängigkeit mit ins Spiel.

Weiterhin fehlt vielen Unternehmen die Möglichkeit, Windows-Store-Apps in einem klassischen Fenster anzuzeigen. Die Kritiker bemängeln, dass sich der neue Startbildschirm mit den Windows-Store-Apps auf der einen und der klassische Desktop auf der anderen Seite wie zwei separate Systeme anfühlen.

Diese beiden Welten werden in Zukunft sicherlich verschmelzen. Es gibt bereits Drittanbieter, die diese Verschmelzung der beiden Welten unterstützen, z. B. bietet die Firma Stardock das Tool ModernMix an. Damit lassen sich Windows-Store-Apps über ein kleines Menü in der rechten oberen Ecke in klassischen Fenstern anzeigen.

Man darf gespannt sein, was in dieser Richtung in Zukunft passieren wird. Laut diversen Leaks soll das erste Update für Windows 8.1 bereits Windows-Store-Apps in der TaskBar auf dem klassischen Desktop anzeigen können. Somit dürfte auch Microsoft die oben erwähnte Verschmelzung vorantreiben. Und mit Windows 9, das in der ersten Jahreshälfte 2015 erscheinen soll, werden sicherlich weitere Neuerungen bezüglich der Verschmelzung des Modern UI mit dem klassischen Desktop auf die Benutzer und die Entwickler warten.

Ein weiteres viel diskutiertes Feature ist das fehlende Startmenü. Dies ist zwar nicht direkt mit den Windows-Store-Apps verbunden, aber neben dem Migrationsaufwand immer wieder einer der Hauptgründe, warum Unternehmen mit ihren Desktopgeräten nicht auf Windows 8.1 umsteigen möchten. Auch hier bieten Dritthersteller Hilfe an. So hat die Firma Stardock neben dem Tool ModernMix eine Komponente namens Start8 im Portfolio. Start8 erweitert Windows 8.1 um ein voll funktionsfähiges Startmenü, wie es der Benutzer aus Windows 7 kennt (Abb. 7).

Abb. 7: Startmenü mit Start8 unter Windows 8.1

Verteilen von Apps

Ist die Unternehmens-App fertiggestellt, steht man vor der Aufgabe, sie zu verteilen. Typischerweise soll sie nicht über den Windows Store bereitgestellt werden, sondern lediglich einem beschränkten Benutzerkreis zur Verfügung stehen. Eine gewöhnliche Installation auf anderen Geräten wie von den klassischen Desktopanwendungen bekannt, ist bei Windows-Store-Apps aus Sicherheitsgründen nicht möglich. Prinzipiell gibt es zum Installieren von Windows-Store-Apps drei Möglichkeiten:

  1. Gewöhnliche Installation wie jede andere Consumer-App über den Windows Store.
  2. Installation via Entwicklerlizenz direkt auf einem Endgerät: Das ist sinnvoll, um die eigene App zu testen und zu debuggen. Diese Variante wird übrigens auch beim Debuggen von Apps mit Visual Studio genutzt. Der Weg über die Entwicklerlizenz ist jedoch nicht für produktive Anwendungen gedacht.
  3. Installation via Sideloading (=Querladen): Hiermit können Unternehmen ihre eigenen Apps direkt auf den Endgeräten der Mitarbeiter installieren.

Für das Sideloading von Windows-Store-Apps gelten wiederum einige Voraussetzungen:

  1. In den Gruppenrichtlinien ist das Zulassen der Installation vertrauenswürdiger Apps zu aktivieren.
  2. Das Endgerät muss zu einer Domäne hinzugefügt werden und Windows 8.1 Enterprise als Betriebssystem installiert haben. Ansonsten muss auf dem Endgerät ein Sideloading-Produktschlüssel (Windows 8.1 Enterprise ohne Domäne, Windows 8.1 Pro, Windows 8.1 RT) installiert werden.
  3. Die Windows-Store-App muss mit dem Zertifikat einer vertrauenswürdigen Stelle signiert werden. Die signierte App wird mit dem beim Erstellen eines App Packages generierten Powershell-Skript Add-AppxPackage installiert.

Die in der ersten Voraussetzung erwähnte Gruppenrichtlinie lässt sich auf einem Rechner lokal einfach über den Group-Policy-Editor anpassen (gpedit.msc). Ist dieser geöffnet, wird in der Baumstruktur im linken Bereich folgender Ordner ausgewählt: Computerkonfiguration/Administrative Vorlagen/Windows-Komponenten/Bereitstellung von App-Paketen. Auf der rechten Seite ist dann der Punkt „Installation aller vertrauenswürdiger Apps zulassen“ zu sehen (Abb. 8). Diese Richtlinie lässt sich hier aktivieren. Befindet sich ein Rechner in der Unternehmensdomäne, kann diese Richtlinie natürlich auch domänengesteuert aktiviert werden.

Abb. 8: Vertrauenswürdige Apps via Gruppenrichtlinie zulassen

Das Aktivieren der Richtlinie führt zu folgendem Registry-Eintrag:

HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsAppxAllowAllTrustedApps = 1

Befindet sich der Rechner mit Windows 8.1 Enterprise in einer Domäne und ist diese Richtlinie aktiviert, lassen sich Windows-Store- Apps bereits mit dem Powershell-Skript Add-AppxPackage installieren. Ist der Rechner nicht in der Domäne oder hat er keine Windows-8.1-Enterprise-Version, wird zum Aktivieren des Sideloadings ein Sideloading-Produktschlüssel benötigt. Dieser lässt sich bei Microsoft im Rahmen der Volumenlizenz beantragten. Microsoft bezeichnet diesen Sideloading-Produktschlüssel übrigens auch als Volume Licensing Multiple Activation Key (MAK).

Zum Installieren eines Sideloading-Produktschlüssels auf einem Rechner wird die Eingabeaufforderung mit Administratorenrechten geöffnet. Darin wird der Softwarelizenzmanager (slmgr) wie folgt verwendet:

slmgr /ipk 

Anschließend wird der Sideloading-Produktschlüssel aktiviert:

slmgr /ato ec67814b-30e6-4a50-bf7b-d55daf729d1e

Die in diesem Befehl angegebene GUID ist immer gleich und dient zum Aktivieren eines Sideloading-Produktschlüssels. Wurde alles korrekt aktiviert, lassen sich Ihre Unternehmens-Apps in der PowerShell via AppxPackage-Befehl installieren. Damit sind alle Voraussetzungen erfüllt und der Installation Ihrer Business-Apps steht nichts mehr im Wege.

Eine Zertifizierung von Windows-Store-Apps, die via Sideloading installiert werden, findet seitens Microsoft natürlich nicht statt. Dadurch sind die Richtlinien des Windows Stores für die eigenen Unternehmens-Apps nicht relevant. Dies kann sehr interessant sein. So lassen sich beispielsweise in mit C++ entwickelten Windows-Store-Apps beliebige native Bibliotheken aufrufen und nutzen.

[ header = Seite 4: Weitere Enterprise-Funktionen in Windows 8.1 ]

Weitere Enterprise-Funktionen in Windows 8.1

Neben den gezeigten neuen Features für Windows-Store-Apps und dem Verteilen von Apps via Sideloading bietet auch Windows 8.1 Enterprise selbst zahlreiche interessante Features für Unternehmen. Mit Windows To Go lässt sich beispielsweise ein via USB-Stick startbares Windows-Image erstellen. Dies ist in Bring-Your-Own-Device-(BYOD-)Szenarien ideal, da Unternehmen auf diese Weise jedem Mitarbeiter für sein eigenes Gerät das vorkonfigurierte Standardsystem zur Nutzung geben können. Ein weiteres für viele Unternehmen hilfreiches Feature in Windows 8.1 ist das direkte Booten zum Desktop.

Unternehmen möchten den Startbildschirm üblicherweise für bestimmte Mitarbeitergruppen einheitlich gestalten. Auch hierfür hat Windows 8.1 Enterprise ein Feature namens Start Screen Control. Darüber lässt sich unternehmensweit über eine Gruppenrichtlinie das Aussehen des Startbildschirms festlegen. Anschließend können Benutzer auf dem Startbildschirm weder Kacheln hinzufügen noch solche entfernen oder verschieben. Auch die Größe der Kacheln lässt sich dann nicht mehr anpassen. Das Aussehen des Startbildschirms ist quasi komplett vorgegeben.

Lokal lässt sich das Start Screen Control mit einer Windows-8.1-Enterprise-Version einfach ausprobieren. Dazu wird ein Powershell-Fenster geöffnet und mit dem export-startlayout Cmdlet das Layout des aktuellen Startbildschirms in eine XML-Datei exportiert:

export-startlayout -path "D:tempExportedLayout.xml" -as xml

Die erstellte XML-Datei kann nun auf demselben oder auch einem anderen Windows-8.1-Gerät via Group Policy Editor (gpedit.msc) angewendet werden. Dazu wird im Group Policy Editor auf der linken Seite der Ordner Benutzerkonfiguration/Administrative Vorlagen/Startmenü und Taskleiste ausgewählt. Auf der rechten Seite ist dann die Richtlinie „Startseitenlayout“ zu sehen (Abb. 9).

Abb. 9: Gruppenrichtlinie für den Startbildschirm

Ein Doppelklick auf die Richtlinie öffnet das Fenster aus Abbildung 10. Darin lässt sich die Richtlinie aktivieren und der Pfad zur zuvor via Powershell exportierten XML-Datei setzen. Fertig! Jetzt werden die Kacheln auf dem Startbildschirm aus der XML-Datei übernommen und lassen sich nicht mehr verändern.

Abb. 10: Die Gruppenrichtlinie wurde aktiviert

Wird die Gruppenrichtlinie für das Start Screen Control in einer Domäne automatisiert angewendet, kann die XML-Datei mit dem Layout auf einem Netzlaufwerk abgelegt werden, worauf jeder Rechner Zugriff hat.

So geht es weiter

Microsoft legt sehr viel Wert auf seine Unternehmenskunden. Die notwendigen Features zum Entwickeln von Unternehmens-Apps und zu deren Verteilen sind bereits vorhanden, auch wenn der Weg an manchen Stellen noch etwas steinig ist.

Wie in der Einleitung dieses Artikels bereits erwähnt, haben viele Unternehmen gerade erst auf Windows 7 umgestellt. Damit sind oft WPF-Anwendungen im Einsatz und Windows-Store-Apps noch gar kein Thema.

Richtig spannend wird es meiner Meinung nach erst mit Windows 9. Üblicherweise überspringen Unternehmen aufgrund des Umstellungsaufwands eine Version ihres Betriebssystems. Da viele Windows 7 im Einsatz haben, dürfte Windows 9 als Ziel der nächsten großen Migrationswelle gelten. Gelingt es Microsoft zudem, die beiden Welten – das Modern UI und den klassische Desktop – noch enger miteinander verschmelzen zu lassen und Windows-Store-Apps auch auf den Desktop zu bringen, rückt diese Anwendungsart plötzlich mehr und mehr in den Vordergrund.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -