Wir sind TechNet auf Facebook TechNet News App für Windows TechNet Austria auf Twitter Georg Binder auf Twitter Gerhard Göschl auf Twitter Martina Grom auf Twitter Toni Pohl auf Twitter
Zugegebenermaßen ist das nicht mehr der neueste Kurs auf der Microsoft Virtual Academy. Nichts desto trotz bietet dieser Kurs immer noch eine Vielzahl an interessanten Informationen. Und gewinnbringend ist der Kurs allemal, siehe Gewinnspiel am Ende dieses Beitrags!!
In diesem kostenlosen Online-Training der Microsoft Virtual Academy wird demonstriert, wie Sie eine Private Cloud planen und aufbauen. Sie lernen alles, was Sie über die Kernanwendungen für Windows Server und System Center wissen müssen, um Ihre virtualisierten und physischen Ressourcen in der Cloud verwalten zu können. Die Referenten der Microsoft Virtual Academy führen Sie Schritt-für-Schritt durch Konfiguration und Management Ihrer Cloud, zeigen Ihnen technische Details und erläutern Ihnen Beispiele dazu.
Da das Training in englischer Sprache abläuft, anbei auch die Inhaltsbeschreibung in englisch:
During the 8 modules of this specialization, you will be introduced to all the elements of building the Microsoft private cloud. You’ll learn how to optimize and deploy the private cloud starting at the infrastructure layer. You’ll also be introduced to advanced virtualization management features and the concept and implementation of the System Center’s private cloud application service model.
After completing all of the modules you will have an understanding of:
Die Inhalte der einzelnen Module:
Also ein ganzer Haufen an interessanten Inhalten, die man dann auch gleich in die Praxis umsetzen kann.
Viel Spaß beim Lernern!!
OK, jetzt aber zum Gewinnspiel: Habt Ihr Verwendung für einen 32GB Memory Stick? Ja? Dann mache ich Euch das folgende Angebot:
Alle die bis zum 14. September diesen Kurs fertiggestellt, in Ihrem MVA Profil sichtbar gemacht und uns rechtzeitig benachrichtigt haben bekommen von uns einen 32GB Memory Stick zugeschickt. Na? Ist das ein Angebot?
Gewinnspielanleitung im Detail:
1.) Kurs “Configuring and deploying Microsoft's Private Cloud” komplett absolvieren (=100% abgeschlossen).
2.) Komplettierte Kurse im MVA Profil sichtbar machen:
3.) E-Mail an Gerhard.Goeschl@Microsoft.com mit dem Link auf das öffentliche MVA-Profil (z.B. http://www.microsoftvirtualacademy.com/Profile.aspx?alias=1053866 Danke Georg für den Hinweis!!
WICHTIG: Um teilzunehmen muss das E-Mail spätestens am 14. September 2014, 23:59 abgeschickt werden!!
Und hier noch das Kleingedruckte (muss leider sein):
Veranstalter ist die Microsoft Österreich GmbH. Teilnahmeberechtigt sind alle Personen mit Hauptwohnsitz in Österreich und einer österreichischen postalischen Zustelladresse. Von der Teilnahme ausgeschlossen sind Mitarbeiter von Microsoft und deren Angehörige sowie Amtsträger. Minderjährige sind teilnahmeberechtigt, wenn der gesetzliche Vertreter in die Teilnahme und in diese Teilnahmebedingungen vorher eingewilligt hat.
Teilnahmevoraussetzung ist die Komplettierung (=100% abgeschlossen) des Kurses “Configuring and deploying Microsoft's Private Cloud” die Veröffentlichung des Kursabschlusses im MVA Profil des Teilnehmers (https://www.microsoftvirtualacademy.com/MyMVA/MyProfile.aspx) sowie die Bekanntgabe per E-Mail an Gerhard.Goeschl@Microsoft.com bis spätestens 14. September 2014 23:59. Es gilt die Datums- und Uhrzeitangabe bei Eintreffen in der Inbox von Gerhard.Goeschl@Microsoft.com. Der Rechtsweg ist ausgeschlossen
Wenn mehr Einreichungen erfolgen als Preise vergeben werden können behalten wir uns vor die Vergabe der Gewinne anhand der Reihung der Meldung durchzuführen und gegebenenfalls den Wettbewerb frühzeitig zu beenden. Wir behalten uns dementsprechend vor, die Teilnahmebedingung gegebenenfalls zu ändern, und hier entsprechend zu veröffentlichen.
Die Gewinner werden per E-Mail verständigt und erklären sich mit der Veröffentlichung des Vornamens und des Anfangsbuchstabens des Nachnamens auf TechNet Austria einverstanden. Der Rechtsweg ist ausgeschlossen und die Ausbezahlung in bar nicht möglich. Mit Ihrer Teilnahme stimmen Sie diesen Teilnahmebedingungen vollständig und bedingungslos zu.
Durch das Absenden Ihrer Daten willigen Sie in die Speicherung Ihrer Daten durch die Microsoft Corporation in den USA und der Microsoft Österreich GmbH ein. Die erhobenen Daten dienen einzig der Auslosung und Benachrichtigung der Gewinner, sie werden nicht zu anderen Werbezwecken genutzt oder an Dritte weitergegeben. Diese Einwilligung können Sie jederzeit mit Wirkung für die Zukunft widerrufen. Ein Widerspruch ist an Microsoft Österreich GmbH, Am Europlatz 3, A-1120 Wien, oder an austria@microsoft.com zu richten.
Mit Windows Server 2012 und Hyper-V kommt ein sehr wichtiges Feature für hoch-verfügbare virtuelle Systeme mit: Hyper-V Replika. Damit kann eine virtuelle Maschine (VM) im laufenden Betrieb von Host A zu Host B transportiert werden. Damit steht ein (asynchrones) Backup einer VM an einem zweiten Server bereit um im Falle eines Ausfalls den Betrieb fortzusetzen.
Es gibt viele Szenarien, wo ein ausfallsicheres System Sinn macht. Je nach Hardware und Aufwand kann dies auch in einer Private Cloud vollautomatisiert oder manuell erfolgen. Das coole dabei ist, dass der Partner-Host sowohl im eigenen LAN als auch entfernt, etwa irgendwo im Internet - im WAN – stehen kann.
Für einen Überblick über Hyper-V Replikation empfehle ich eine Lektüre in TechNet in Hyper-V Replica Feature Overview und Hyper-V Replica Overview .
Hyper-V Replikation kommt in vielerlei Geschmacksrichtungen. In vielen Fällen wird die Replikation innerhalb eines Netzwerkes (LAN) erfolgen. Hier steht dann im Regelfall ein Domaincontroller zur Verfügung, der sich um Authentifizierung kümmert. Hyper-V Cluster können den IT-Betrieb von virtuellen Maschinen vollständig automatisieren und sicherstellen.
Neben dieser Umgebung im eigenen Unternehmen habe ich jedoch ein Szenario, wo Hyper-V Hosts außerhalb meines LANs – und ohne Domaincontroller – mit Hyper-V Replikation laufen sollen, etwa bei einem Internet-Provider. In meinem Fall sollen VMs ge-backupt werden. Bei Ausfall ist es ausreichend, ein manuelles Failover durchzuführen.
Die Besonderheit dabei: Die Replikation erfolgt ohne Domaincontroller über WAN.
Bei Bedarf wird eine VM auf dem Partner-Host aktiviert – man spricht hierbei von Failover.
Wenn etwa VM1 auf Host A nicht mehr funktioniert, wird die Replik (die Kopie) auf Host B in Betrieb genommen. Wenn Host A wieder funktioniert, kann die VM wieder zurückverschoben werden und wieder auf dem Original-Host A weiterlaufen.
Hierzu empfiehlt es sich, etwa gleich starke Hosts zu verwenden, welche die Kapazität haben, alle VMs zu übernehmen. Natürlich kann das Szenario auch auf mehrere Partner-Hosts ausgeweitet werden, etwa mit 3 oder 4 Hosts, wo VMs aufgeteilt werden. Die Host-Hardware muss nicht gleich sein, das empfinde ich als großen Vorteil. Als Software kommt auf beiden Seiten Windows Server 2012 R2 zum Einsatz.
Der erste Schritt besteht darin, die Hyper-V Replikation zu aktivieren. Das erfolgt in den Hyper-V Settings.
…und in Replication Configuration. Hier stehen zwei Transport-Mechanismen zur Verfügung:
Für mein Szenario muss also Zertifikat-basierende Authentication zum Einsatz kommen. Die zu erreichende Konfiguration sieht so aus:
Ohne AD benötigen wir also Zertifikate auf den Hyper-V Servern. Hierbei gibt es wieder zwei Möglichkeiten: Man kauft offizielle Zertifikate, oder man erstellt sie einfach selbst. Ich habe mich für Weg zwei entschieden: Selbst erstellte Zertifikate. Wir gehen dabei von zwei Hyper-V Hosts aus.
Der Vorgang ist nicht schwer – wenn man weiß wie. Ich habe nach etwas Recherche eine gute Anleitung von Bonn Tee im australischen blog.powerbiz.net.au gefunden: How to create Self-Signed Certificates for Hyper-V Replication. Hier sind die wesentlichen Schritte dokumentiert.
Dazu benötigt man zunächst auf beiden Servern das Tool MakeCert.exe. Informationen über MakeCert.exe sind in im MSDN unter Makecert.exe (Certificate Creation Tool) und in Working with Certificates zu finden. Entwickler habens gut, das Tool kommt automatisch mit Visual Studio mit (etwa in C:\Program Files (x86)\Windows Kits\8.1\bin\x64). Alternativ kann es von hier MSDN: MakeCert bzw. direkt von hier downgeloadet werden.
Nun muss auf jedem Server ein mit MakeCert ein Zertifikat erstellt werden. Für Host A lautet dies mycompanyFirstReplica und für Host B mycompanySecondReplica.
Achtung: Der CommonName (CN) des Zertifikates muss dabei exakt wie der FQDN (Full Qualified Domain Name) in System lauten!
Nun wird – auf beiden Hosts – ein Command Prompt als Administrator geöffnet und diese Schritte ausgeführt (Host beachten und die Parameter auf die eigene Firma und CN´s anpassen):
makecert -pe -n "CN=mycompanyFirstReplica" -ss root -sr LocalMachine -sky signature -r "mycompanyFirstReplica.cer"
makecert -pe -n "CN=HOST4.atwork.at" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "mycompanyFirstReplica" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 FirstServer.cer
makecert -pe -n "CN=mycompanySecondReplica" -ss root -sr LocalMachine -sky signature -r "mycompanySecondReplica.cer"
makecert -pe -n "CN=HOST5.atwork.at" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "mycompanySecondReplica" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 SecondServer.cer
certutil -addstore -f Root "mycompanySecondReplica.cer"
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
certutil -addstore -f Root "mycompanyFirstReplica.cer"
Wenn mehr als zwei Hyper-V Hosts beteiligt werden sollen, sind die Schritte oben für alle Partner anzupassen bzw. auszuführen, etwa mycompanyThirdReplica usw. Alle Partner müssen die Zertifikate der anderen beteiligten Server besitzen und ihnen vertrauen.
Wenn die Zertifikate erstellt und in den Computer-Zertifikatsstore importiert wurden, sollten wir kontrollieren, ob auch alles geklappt hat:
MMC.exe starten und mit File/Add/Remove Snap-in (oder CTRL-M) das Snap-In Certificates hinzufügen und Computer account und Local Computer auswählen. In Certificates (LocalComputer) / Personal / Certificates muss nun das eigene Zertifikat aufscheinen, wie hier:
Zweitens muss in den Trusted Root Certification / Certificates das hinzugefügte Zertifikat des Partner-Hosts vorhanden sein, wie hier:
Wir sehen in denTrusted Root Certification sind die Zertifikate beider Hosts vorhanden. Und wir vertrauen diesen Zertifikaten. Dasselbe Szenario auch auf dem Partner-Host kontrollieren. Das wars dann mit den Zertifikaten.
Nicht zu vergessen, ist dass der Hyper-V Replikationsdienst durch die Windows Firewall kommen muss.
Dazu die Windows Firewall with Advanced Security öffnen und in den Inbound Rules den Dienst für Hyper-V Replica HTTPS aktivieren (Enable Rule). Die Firewall soll wie im Screenshot konfiguriert sein und den HTTPS Listener aktiviert haben.
Nicht vergessen, die Firewall-Einstellungen auf ALLEN Hosts zu setzen…!
Wenn diese Voraussetzungen erfüllt sind, gehts los mit dem Einrichten der Hyper-V Replika für einzelne VMs. Das zeigen wir in Teil 2!
... ab September geht es wieder richtig los - ob PowerShell, Outlook, SCCM, SCOM, Windows Server oder SharePoint, unsere Technologien werden ab Herbst wieder in großer Vielfalt angeboten!
In den Workshops können Sie die neuen Microsoft Technologien live und hands-on kennenlernen, in jeweils mehrtägigen, praxisorientierten Veranstaltungen und unter Anleitung unserer erfahrenen Experten.
Riskieren Sie einen Blick auf unsere WEBSITE: http://www.microsoft.com/de-at/services/PremierWorkshops.aspx
Bei Fragen einfach eine Email an atpremev@microsoft.com schicken.
Liebe Grüße, Eva
Das Microsoft Azure Team versendet zur Zeit Newsletter, wo Azure-Kunden darüber informiert werden, dass in Kürze Azure-Subscription-Administratoren Mitglied des Azure-Active Directories sein müssen.
Als Nutzer eines Azure Abonnements (subscription) kann man sich auf zwei Arten am Azure-Portal (oder an einer Azure-API) anmelden: a) mit einem Microsoft-Konto oder b) mit einem Organisations-Konto.
Ein neues Microsoft-Konto kann jederzeit online unter https://signup.live.com angelegt werden. Ein Organisations-Konto heißt, dass das Konto im Azure Active Directory (AAD) vorhanden sein muss, etwa in einem Office 365-Tenant. Dieser kann ebenfalls online als Testabo für 30 Tage neu angelegt werden.
Während es bis vor gar nicht allzu langer Zeit erforderlich war ein Microsoft Konto zu benutzen kann die Administration nun auch mit einem Unternehmens-Konto erfolgen – das heißt, mit einem Login aus einem Azure Active Directory. Lokale AD-User können mit Tools wie DirSync oder ADFS in die Cloud synchronisiert werden – so benutze auch ich mein Organisationskonto in der Cloud.
Die Idee: Single Sign On und eine stark vereinfachte Verwaltung: Mit einem Organisationskonto können mehrere Subscriptions einfacher verwaltet werden als mit (unterschiedlichen) Microsoft-Konten.
Diese Umstellung macht aus meiner Sicht (neben den neuen angekündigten Features) also wirklich Sinn... in Zukunft. Dazu später mehr.
…sieht so aus:
Der relevante Teil dabei ist jene Information:
“Azure will soon require administrators to be registered in Azure Active Directory to be able to sign into the Azure Management Portal or use the Azure management API. Microsoft Accounts being used as subscription administrators will be added as Guest accounts in the directory if they aren’t already registered in the directory.”
Etwas mehr Informationen erhält man im TechNet in Prepping for new management features.
Das Azure-Team wird einige neue Funktionen einbauen, welche die Authentifizierung mit einem AD-Konto erforderlich machen. Somit werden Azure-Subscriptions auf AD-Authentifizierung umgebaut:
“Your Microsoft Azure subscriptions uses Azure Active Directory to sign users in to the management portal and to secure access to the Azure management API. In preparation for upcoming management capabilities, Microsoft is ensuring that all Azure subscription administrators are members of the directory that secures access for that subscription. Microsoft accounts being used as subscription administrators will be added as Guest accounts in the directory if they are not already registered in the directory.“
In Azure-Abos, die von einem Microsoft-Konto administriert werden, wird das Microsoft-Konto in das Azure-Subscription-AD als Gast hinzugefügt.
OK. soweit so gut.
Schon bald: am 31. August – also diese Woche.
“Azure will soon require administrators to be registered in Azure Active Directory to be able to sign in to the Azure portal or use the Azure management API. The Guest accounts will be added by August 31st 2014.“
Die gute Nachricht ist: Nein.
Alle Microsoft-Admin-Konten werden automatisch mit Ende August in das AD der subscription hinzugefügt.
“These users do not need to take any action. For more information on Guest accounts including how to search in the directory for them, please see: Prepping for new management features”
Die so ins AD hinzugefügten Microsoft-Konten erhalten im Feld “department” den Hinweis “Created as guest by Microsoft Azure”. Um alle importierten User auszulesen, kann – nach Anmeldung am AD mit einem Administrator via Connect-MsolService - das PowerShell Office365-Commandlet Get-MsolUser -All -Department "Created as guest by Microsoft Azure" verwendet werden.
Connect-MsolService
Get-MsolUser -All -Department "Created as guest by Microsoft Azure"
Mit diesen Konten können (eingeschränkt) Informationen aus dem eigenen AD gelesen werden. Die Einschränkung des Guests bedeuten, dass nur bestimmte Objekte wie andere User oder Gruppen und nur bestimmte Felder gelesen werden können (limited access).
Um in AD einen Guest zu einem nicht eingeschränkten Mitglied zu machen, kann dieses Office365 Commandlet verwendet werden: Set-MsolUser -UserPrincipalName user@company.com -UserType Member
Set-MsolUser -UserPrincipalName user@company.com -UserType Member
Ja. Der einzige Unterschied ist, dass das verwendete Microsoft-Konto nun auch Mitglied des Azure-eigenen ADs ist – was aber keinen Einfluss auf die Verwaltung von Azure-Subscriptions hat.
Um es klar zu machen: Die Azure-Verwaltung mit einem Microsoft-Konto funktioniert dann genauso wie zuvor.
So wird sich mancher (wie auch ich) jetzt denken: Ok, wenn Microsoft umstellt, dann brauche ich mein Mircosoft-Konto ja eigentlich nicht mehr, und stelle die Administration auf mein (zB. gesynchtes) Organisations-Konto um.
Um es vorweg zu nehmen: Eine gute Idee. Aber das geht jetzt noch nicht… (siehe auch Teil 2).
wird das Microsoft-Konto weiter gebraucht. Bei meinen Versuchen und Recherche habe ich festgestellt, dass (derzeit) ein Microsoft-Konto erforderlich ist, siehe http://support.microsoft.com/kb/2969548 vom 29. Mai 2014:
“When you try to add a co-administrator for your Microsoft Azure subscription, you receive the following message: The co-administrator must be either a Microsoft Account or a user account homed in the Default directory.
Cause: Your Azure subscription has a default directory associated with it, and only users who have Microsoft accounts in this default directory can be co-admins.”
Also klappt das jetzt nicht ohne Microsoft-Konto.
…funktioniert der Wechsel (jetzt noch) nicht. Microsoft wird dies wohl erst in naher Zukunft einbauen.
In Teil 2 sehen wir uns an, wie man ein Organisations-Konto verwenden kann und wie der aktuelle Status davon aussieht.
Erfolgreiche Technologieexperten hören nie auf zu lernen. Großartige Technologien hören nie auf sich zu entwickeln. Die Microsoft Virtual Academy (oder MVA) bietet Microsoft-Onlineschulungen durch Experten, um Technologieexperten beim Lernen behilflich zu sein.
Dieser MVA Kurs “Servermanagement und Automatisierung inkl. PowerShell 4.0” richtet an Administratoren, die einen Einstieg in die Windows Server 2012 Administration suchen. Wir zeigen die Verwaltung über die GUI mit dem neuen Server Manager, mit dem jetzt auch eine Multi-Server Administration von einem Windows 8.1 Client möglich ist. Wir führen verschiedene Arbeitsschritte durch, z.B. das Installieren von Rollen auf entfernten Servern, das Einrichten von Netzwerk-Teaming und Storage Pools und machen einen Best Practise Analyzer Sicherheits-Scan gegen einen unserer Webserver. Im zweiten Teil widmen wir uns der Automatisierung mit PowerShell. Was ist möglich mit der PowerShell und wie fange ich an? Exemplarisch skripten wir mit der PowerShell rund um Active Directory und Hyper-V und zeigen nützliche Features wie z.B. die PowerShell History im Active Directory Administration Center. Zum Abschluss zeigen wir, was die PowerShell 4.0 mit der Desired State Configuration bringt.
Trainer: Bernhard Frank, Technical Evangelist, Microsoft Deutschland GmbH und Carsten Rachfahl, MVP für Virtual Machine und Geschäftsführer der Rachfahl IT Solutions GmbH und Co. KG.
Module
Jetzt den MVA Kurs “Servermanagement und Automatisierung inkl. PowerShell 4.0” starten!
Die Zielsetzung ist es, Entwicklern, kompetenten IT-Experten und fortgeschrittenen Studenten beim Erlernen der neuesten Technologien, Ausbauen ihrer Fähigkeiten und Fördern ihrer Karrieren zu helfen. Die MVA ist kostenlos. Der gesamte Dienst wird in Windows Azure gehostet.
Am 12. August war Patchday. Mit den vielen Updates wurde auch Update 2982791 mit ausgeliefert. Microsoft empfiehlt, dieses Update wieder zu deinstallieren, da es zu Startproblemen führen kann. Betroffen sind vor allem Windows 7 Maschinen.
Dieses Security Update behebt drei Sicherheitsschwachstellen, die zu unbefugten erhöhten Zugriffsrechten führen und wird von Microsoft in einer überarbeiteten Version wieder neu zur Verfügung gestellt.
Der Originaltext der E-Mail Notifikation:
MS14-045 - Important - https://technet.microsoft.com/library/security/ms14-045 - Reason for Revision: V2.0 (August 15, 2014): Bulletin revised to remove Download Center links for Microsoft security update 2982791. Microsoft recommends that customers uninstall this update. See the Update FAQ for details. - Originally posted: August 12, 2014 - Updated: August 15, 2014 - Bulletin Severity Rating: Important - Version: 2.0
Beschreibung des Updates und Infos zur Deinstallation – der Download Link für das Update wird nicht mehr ausgeliefert, für jene, die das Update bereits installiert haben: in der Systemsteuerung unter Programme / Installierte Updates das Update heraussuchen und deinstallieren.
Bei vielen Gesprächen habe ich seit der offiziellen Präsentation des Windows Phone 8.1 Betriebssystems auf der Build 2014 Konferenz Anfang April immer wieder Dinge gehört, die häufig als Mythen klassifiziert werden müssen. Heute möchte ich beginnen Fakten dazu festzuhalten und damit hoffentlich einen Beitrag zu objektiven Diskussionen bei Vergleichen mit anderen Plattformen leisten zu können. Bei Bedarf werde ich diese Auflistung aktualisieren/ergänzen.
M: Windows Phone 8.1 sieht viel versprechend aus, ist aber noch in Beta und nur als Developer Preview für bestehende Windows Phone 8.0 Geräte zu laden.
F: Jede über das Developer Preview Programm veröffentliche Windows Phone 8.1 Version (und auch seinerzeit erstmals ab Windows Phone 8 Update 3) ist ein finaler RTM (Release to Manufacturing) Build. Man kann sich das etwas so wie beim “großen Bruder”, dem Windows für PCs und Tablets vorstellen. Windows wird zu einem bestimmten Zeitpunkt fertig gestellt (RTM), PC Hersteller bekommen die RTM Bits zur Integration in neuen Systemen (Treiber etc.) und Entwickler können über ein MSDN Abo zum Testen ihrer Anwendungen darauf zugreifen. 2 bis 3 Monate später wird das neue Windows offiziell für den Handel freigegeben, PCs dürfen mit dem neuen Windows vorinstalliert ausgeliefert und die Windows Updatepakete im Handel für bestehende Windows Benutzer zum Kauf angeboten werden. Weil Windows Phone Smartphones identische Mindestanforderungen an die Hardware der Hersteller haben, kann mit der Developer Preview das fertige (RTM) neue Windows Phone Betriebssystem als Upgrade installiert werden, ohne dass der Handy Hersteller (OEM) die UEFI Firmware speziell für das neue Betriebssystem angepasst oder zumindest zertifiziert hat. Jeder Hersteller kann, aber muss nicht, eine neue Firmware mit dem neuen Windows Phone ausliefern. Hat ein Benutzer mit Hilfe der Developer Preview bereits das Windows Phone Betriebssystem aktualisiert wird bei der Freigabe der UEFI Firmware nur mehr diese über den Updateprozess aktualisiert. Der glückliche Benutzer merkt ab diesem Zeitpunkt keinen Unterschied, ob das Betriebssystem schon vor der Firmware aktualisiert worden ist.
Mittlerweile sollte sich dieses Gerücht auflösen, weil neue Smartphones (bei Nokia Lumias sind das alle Smartphone der 30er Serie) mit Windows Phone 8.1 und der neuen Lumia Cyan Firmware ausgeliefert und schrittweise alle bestehenden Windows Phone 8.0 Geräte (bei Nokia Lumias sind das alle Smartphones der 20er Serie) aktualisiert worden sind oder in Kürze aktualisiert werden. Alle registrierten Developer Preview Benútzer bekommen nach wie vor die neuesten fertigen (RTM) Windows Phone Builds bevor sie von den Handyherstellern (OEMs) und bei Provider-gebundenen Geräten auch von den Mobilfunkanbietern (MOs) gestestet und freigegeben werden.
M: Windows Phone kann man im Unternehmen nicht einsetzen, weil es sich nicht oder schlecht in MDM Lösungen einbinden lässt.
F: Für Windows Phone 8.0 gilt das grundsätzlich. Wir haben primär eine solide und sichere Plattform gebaut und die Verwaltung auf Exchange ActiveSync Policies und ein paar MDM Policies beschränkt. Mit Windows Phone 8.1 wurden neben vielen anderen Dingen auch unzählige Policies für die granulare Kontrolle implementiert.
M: Windows Phone wird oft als Alternative zu BlackBerry positioniert, ich kann aber keine Einstellungen für die Kontrolle der mobilen Datenverbindung im Ausland finden.
F: Wir positionieren Windows Phone 8.1 als sichere Alternative zu BlackBerry aber keine spezielle Infastruktur. In so fern verhält sich das Windows Phone 8.1 gleich wie BlackBerry 10 Geräte, die ebenfalls die normalen mobilen Datentarife der Mobilfunkanbieter nutzen. Eine Infrastruktur wie bei älteren BlackBerry Geräten, mit günstigen Tarifen im “eigenen” gibt es weder bei neuen BlackBerry, noch bei Windows Phone.
M: Windows Phone ist für Unternehmen nicht einsetzbar, weil es nicht einmal einen Virenschutz gibt.
F: Das Windows Phone Betriebssytem (nicht erst 8.1) ist “secure by design”. Jedes Telefon, ob günstiges Einsteiger- oder hochwertiges Businessgeräte, hat identische Sicherheitsmerkmale. Das beginnt bei der Hardware mit einem TPM-fähigen Chip, UEFI Firmware, Geräteverschlüsselung mit BitLocker Technologie und Sandboxes für jede App. Eine App kann nur den eigenen Speicher verwenden, eine AV App könnte sich also selbst scannen.
M: Windows Phone kann nicht in bestehende MDM Lösungen eingebunden werden, weil es für keine dieser Lösungen einen Agent gibt.
F: Durch die sichere Architektur eines Windows Phones ist es tatsächlich so, dass keine App (und damit auch kein MDM Agent aus dem Store, wenn man mit anderen mobilen Plattformen vergleicht) die Funktionalität des Betriebssystems erweitern kann. Der MDM Agent wurde im Windows Phone 8.1 extrem erweitert und bietet native die Möglichkeit das Smartphone granular mit Richtlinien einzustellen. Die technischen Möglichkeiten sind dokumentiert und stehen jeder MDM Plattform gleichwertig über OMA-DM zur Verfügung. Auch die Microsoft MDM Lösungen Windows Intune optional mit System Center Configuration Manager nutzen diese dokumentierte Schnittstelle. Alle namhaften Hersteller von MDM Lösungen haben frühzeitig die identischen und vollständigen Informationen der OMA-DM Steuerungsmöglichkeiten für Windows Phone (8.0, später 8.1) erhalten. Jeder Hersteller kann entscheiden welche Funktionalitäten er mit seiner Lösung unterstützen will; es kommt durchaus vor, dass die vollständige Windows Phone 8.1 Unterstützung in mehreren Schritten erfolgt, Windows Phone 8.0 war für einige Hersteller den Aufwand der Integration (mit wenigen Funktionen) nicht wert. Oft wird jetzt die Unterstützung von Windows 8.1 und Windows Phone 8.1 (beide können über OMA-DM gesteuert werden) mit einem gemeinsamen Windows Modul für Tablets und Phones angeboten.
M: Windows Phone kann im Unternehmen nicht verwendet warden, weil es keine Container zur Abgrenzung zwischen geschäftlichen und privaten Apps/Daten gibt.
F: Jede am Windows Phone installierte App läuft in einem Container (Sandbox). Weder private noch geschäftliche Apps können (bösartig) auf den Speicher anderer Apps zugreifen. Geschäftliche Apps (LOB Anwendungen) werden mit einem Unternehmenszertifikat signiert. Sollen alle geschäftlichen Inhalten (Apps und Daten) von einem (privaten) Windows Phone gelöscht werden, dann werden alle mit dem Unternehmenszertifikat markierten “Container” identifiziert und gelöscht.
M: Ich möchte Windows Phone nicht im Unternehmen einsetzen, weil die Plattform noch nicht verbreitet ist und die Entwicklung und Wartung meiner Geschäftsanwendung auf so vielen Plattformen (Codebasen) finanziell nicht vertretbar ist. Es ist teuer genug Anwendungen für den Windows Desktop (Windows 7 und 8.1), Windows Tablets/Laptops/2-in-1 (Windows 8.1), iOS (iPad, iPhone) und Android (Smartphones, Tablets) zu betreiben.
F: Windows Phone 8.1 unterstützt wie Windows 8.1 sog. Universal Apps, die eine gemeinsame Shared Source haben. Solche Apps haben auf beiden Plattformen das AppX Format. Natürlich unterstützt das Windows Phone 8.1 auch die bis dahin gültigen Windows Phone 8.0 Apps im XAP Format. Mit Visual Studio 2013 lassen sich Universal Apps für beide neuen Windows Plattformen erstellen.
Sollen mobile Apps für iOS, Android und Windows Phones erstellt werden und ist C# Wissen vorhanden, dann können solche Apps einmal programmiert und mit Xamarin für alle drei Plattformen erzeugt werden.