blog.atwork.at

news and infos about microsoft, technology, cloud and more

Was Microsoft aus dem Cloudbusiness mit Azure gelernt hat #CloudFail #CloudAwesome

Mit der Build in San Francisco gibt es wieder jede Menge Neuigkeiten rund um Azure zu berichten. Einen sehr interessanten Beitrag gab es von Mark Russinovich. Als Technical Fellow im Azure Team hat er dieses Mal eine ganz neue Session gehalten, die abseits von seinen Sysinternals, Malwarehunting und Case of… Vorträgen sehr authentisch gezeigt hat, welche Erfahrungen Microsoft im Dauerbetrieb einer Business Cloud Lösung gesammelt hat und worauf man als Rechenzentrumsbetreiber achten sollte. Bereits letztes Jahr hatte ich einmal die Gelegenheit einer Q&A Session von Mark zu hören, wo er über Clouderfahrungen und zukünftige Entwicklungen berichtet hat. Eine der wichtigsten Botschaften lautet: Automatisiere soviel als möglich und setze Dich nicht über diese Automatisierungen hinweg. Das klingt natürlich ein bisschen nach SkyNet, auch die Tatsache, dass alle diese Fehler, die Mark erzählt hat, vermeidbar gewesen wären. Manche davon sind evident, eines haben alle Fehler gemeinsam, die in einem Public Cloud Umfeld geschehen: sie sind schmerzhaft, fallen auf und sind zum Teil natürlich vermeidbar. Wichtige Themen rund um einen Rechenzentrumsbetrieb: Automatisiere Skaliere Teste in Produktion (!!!) Frühe Deployments, häufige Deployments In Azure werden Incidents nach Schweregrad gemessen: Severity 3: nicht dringend, keine Kundenbeeinflussung, kann später einen Einfluss haben. Severity 2: beeinträchtigt manche Kunden und manche Services. Dringend, aber noch keine Katastrophe. Severity 1: globaler Ausfall, der mehrere Services betrifft und mehrere Kunden. Severity 0: sehr großes Problem, Kunden laufen Gefahr, ihre Daten zu verlieren. In Azure gab es einmal einen Severity 0 Fall. Beispiele von aufgetretenen Fehlern: 1. Case-Sensitive Check beim Ressourcenprovider. D.h. “mobileservice” <> “MobileService”, RDFE erwartet Case-sensitive. 2. Sauberes Logging Jeder Developer sollte eine saubere Fehlerprotokollierung implementieren. Fehlermeldungen wie: “Das Abonnement ist nicht für dieses Feature vorgesehen” oder “Der Servicename ist unbekannt” ist schwierig zu finden. Build with /warnaserror. Don’t supress compiler warnings. 3. Exceptional Coding Catch-all oder fail fast? Bekommt jemand einen Fehler ist es ganz normal, dass derjenige es noch einmal probiert. Mit catch-all fängt man alle Fehler ab, es kann jedoch trotzdem instabil sein. Ein fail-fast führt aufgrund der wiederholten Versuche eventuell zu einer Denial of Service Attacke. Ein Tipp ist: crash wenn es sich nicht um einen Userfehler handelt, andernfalls logge einen Fehler. Log einmal pro Stunde, damit eine Fehlerlog nicht von ein und derselben Fehlermeldung angefüllt wird. 4. VM werden nicht provisioniert In diesem Fall wurden neu erzeugte VM’s in Azure nicht provisioniert. Das passierte nur bei 2 aktualisierten, brandneuen Images. Der Vorgang der Provisionierung in Azure ist dabei folgender: monatlich werden OS VHD Images neu erzeugt, die Images werden in ein repository geladen und die Funktionalität wird manuell getestet. Danach werden diese VHD’s vom staging Bereich in den Produktivbereich geladen. Während dieses Vorganges wurden die Images kaputt. Das Learning daraus ist: nicht nur im Staging Bereich testen, sondern auch in der Produktivumgebung, da Daten kaputt gehen können. 5. VIP swap Ein VIP Swap ist die Umstellung einer Staging Umgebung in den Produktivbetrieb. Man deployt 2 Versionen seiner Cloud Services – Produktion und Stage. RDFE verwendet dazu Storage Tables um sich die beiden Versionen zu merken. Durch einen Bug in RDFE kam es dazu, dass diese Zeilen falsch überschrieben wurden – beide Zeilen zeigten an, die Stage Version zu sein. Updates erfolgen daher immer nur scheibchenweise. 6. Löschen von Subscriptions Interne Azure subscriptions werden von Zeit zu Zeit aufgeräumt. Bei diesen Subscriptions gab es auch welche, die für Kunden in einem Preview Stage erzeugt wurden. Dazu gibt es einen Prozess, mit dem diese aufgeräumt werden. Die damals dafür verantwortliche Personen erzeugten einen Batch und haben mit diesem den dafür vorgesehenen Prozess übersteuert. Folge war, dass viele Subscriptions, auch von Kunden, gelöscht wurden. Alle Daten konnten glücklicherweise wieder hergestellt werden, da Azure Data Retention verwendet und Daten für 90 Tage weiterhin verfügbar sind. Zudem verwendet Azure, wo immer möglich Soft Delete. 7. Zertifikat Ablauf Dies ist einer der Fälle, die weitläufig bekannt wurden. Am 22. Februar 2013 kam es zu einem Zertifikatausfall, der nahezu 11,5 Stunden dauerte, bis die volle Verfügbarkeit wieder hergestellt war. SSL Verbindungen waren plötzlich nicht mehr möglich. In diesem Fall lag es nicht daran, dass Microsoft vergessen hatte, die Zertifikate zu erneuern, bereits 180 Tage vorher werden Warnungen ausgegeben, dass diese zu erneuern sind. Diese werden aktualisiert, in diesem Fall waren es drei Zertifikate, die bereits im Jänner 2013 erneuert wurden. Der Fehler hierbei war, dass vergessen wurde, diese Zertifikate mit einem Update Datum zu versehen. Dadurch passierte, dass andere Updates vorgezogen, bzw. dieses eine Update nach hinten, nach den 22. Februar verschoben wurde. Microsoft scannt nun wöchentlich alle Service Endpoints. Microsoft arbeitet hier auch an einer Vollautomatisierung. 8. Schaltjahr in Azure Zeit ist ein single point of failure. Das große Learning hieraus ist, dass Menschen Fehler machen, durch Automatisierung können diese vermieden werden. Ein Übersteuern der definierten Prozesse kann einfach schlimme Folgen haben. Tolle Session von Mark, es war eine Premiere auf der Build, hoffe, viele ergreifen die Gelegenheit und sehen sich diese Session an. Eine offene Kommunikation über gemachte Fehler und was daraus gelernt wurde, hilft uns, diese selbst in Zukunft zu vermeiden und auch mehr Vertrauen in Cloudservices zu bekommen.

I Am MEC–Session about Remote Control Office 365 with Microsoft Azure

This week, from March 31th to April 2nd, the Microsoft Exchange Conference 2014 takes place in Austin, Texas. Austin is a great city and it´s fun to be here an to be part of the conference! Find our slides and our code sample here.

Office 365–Neuerungen bei SharePoint Online

Office 365 wächst und wächst und wächst. Wir sehen täglich, wie die Services erweitert werden und Limitierungen erweitert und gelöst werden. Seit April 2013 sind sowohl die Zugriffe als auch die gespeicherten Daten um mehr als 480% gestiegen. Bereits jetzt erhalten Benutzer eines E3 Planes standardmäßig 25GB OneDrive for Business Storage, 50GB Mailboxstorage, ein unlimitiertes E-Mail Archiv, 5GB für SiteMailboxen, 10GB für jede Shared Mailbox. Eine Erweiterung wurde letzte Woche bekannt gegeben, die der Verwendung von SharePoint Online enorm hilft: das Sitecollection Limit wurde auf 1TB / Sitecollection erweitert. Bisher war es möglich, pro Sitecollection max. 100GB an Daten zu speichern, was bei großen Sitecollections schon mal für Unmut gesorgt hat, da man bereits bei der Architekturplanung des SharePoint Tenants darauf achten musste, wie die Lösung angelegt wird. Ein zweites Limit betraf die Tenantgröße: 25 TB waren bisher das Maximum, nun ist die Aussage: unlimitiert. Auch OneDirve for Business (ehemals SkyDrive pro) kann jetzt bis zu 1 TB groß werden. Eine kurze Zusammenfassung der Limits bei SharePoint Online in den Enterprise Plänen: SharePoint Online Tenantgröße: unlimitiert Sitecollection: 1TB / Sitecollection Sitecollections / Tenant: 10.000 Subsites / Sitecollection: 2.000 OneDrive for Business: 25GB Standardmäßig, erweiterbar auf 1TB FileUpload Limit: 2GB Probieren Sie Office 365 aus – dazu können Sie entweder einen 30 Minuten anonymen Sofort-Test eine voll funktionsfähigen Office 365 Tenants verwenden oder Sie registrieren einen kostenlosen 30 Tage Test.

Die eigene Domain in Windows Intune zum Mobilen Device Management verwenden

Window Intune hilft Unternehmen bei der Verwaltung Ihrer Client Computer, Windows RT Geräten, Windows Phone Geräten bis hin zu iOS Devices. Seine Stärken hat es vor allem im Bereich des mobilen Device Managements, in Kombination mit System Center wird das Management der Infrastruktur übersichtlich und vorsorgend. Wenn Windows Intune konfiguriert wird und Sie mobile Geräte hinzufügen möchten, können Sie hierbei auch Ihre eigene Domain verwenden. Diese Einstellung treffen Sie in der Verwaltungskonsole unter Verwaltung / Verwaltung mobiler Geräte und dort bei Windows Phone. Wie das DNS Management zu erfolgen hat ist in diesem TechNet Artikel beschrieben. Dabei sind mir ein paar Kleinigkeiten aufgefallen, die ich hier gerne beschreiben möchte, damit die Eisntellungen leichter klar sind: Verwenden Sie, wenn Sie keine eigene Domain angeben immer die Adresse enterpriseenrollment-s.manage.microsoft.com für die Verbindung eines mobilen Gerätes. Bei Angabe einer eigenen Domain müssen Sie einen CNAME Eintrag setzen, der folgendermassen aussieht:enterpriseenrollment.contoso.com auf enterpriseenrollment.manage.microsoft.com. Wichtig hierbei ist, dass der CNAME tatsächlich enterpriseenrollment ist. Beim verifizieren, verwenden Sie nicht den CNAME Eintrag, sondern die Root Domain. Viel Erfolg mit Windows Intune!

Windows Intune–add your custom enrollment address for your mobile device management

In the last couple of weeks I did a lot Windows Intune POC’s with Demo Customer environments. Windows Intune is a great tool for mobile device management, you can add Windows Devices as well as your Windows Phones and iOS Devices. Mobile Device Management made easy, so you can manage your devices. To setup Mobile Device Management you have first decide what the authority of your Mobile Device Management is. Since I am a public cloud addicted, I use Intune the plain way. Of course you can also configure it together with your System Center infrastructure. After you have set that you can now start configuring your Mobile Device Management. If you want to add your mobile devices you’ve to name a management server. In most cases I left it how it was, enterpriseenrollment-s.manage.microsoft.com. Some customers prefer to add their own domain and that’s what today’s article is about. The Technet Documentation describes to add a CNAME record for your domain and afterwards verify it. As someone who knows DNS I thought Intune won’t care, which name my CNAME record has, the only important thing is the correct endpoint which is enterpriseenrollment.manage.microsoft.com. So here is the first thing to be aware of: If you add your mobile device manually you have to use enterpriseenrollment-s.manage.microsoft.com. If you try enterpriseenrollment.manage.microsoft.com you cannot add the device. So I set a CNAME for mdm.contoso.com to enterpriseenrollment.manage.microsoft.com. Try to verify it: Why? nslookup shows that everything is correct. So I tried to do it as Technet says: enterpriseenrollment.contoso.com to enterpriseenrollment.manage.microsoft.com Verification fails again. The trick is: Add the CNAME record for contoso.com to enterpriseenrollment.contoso.com. To verify that, simply verify it with the root domain and everything works. Have fun using your own Domain in mobile device management.

Bye bye InfoPath

Das Microsoft Office Team hat in seinem Blog angekündigt, dass InfoPath und SharePoint Formulare in Zukunft nicht weiter entwickelt werden. In dem Artikel Update on InfoPath and SharePoint Forms schreibt das Office Team, dass InfoPath 2013 die letzte Version des Desktop Clients und InfoPath Forms Services in SharePoint Server 2013 die letzte Version der InfoPath-Technologie sind.

Hidden Features von Office 365: Auswertungen von Exchange Online leicht selbst erstellen

Office 365 bietet bereit viele eingebaute Reports, mit denen allerlei Funktionen ausgewertet werden können. Diese Reports befinden sich im Dashboard unter den Berichten und sind jederzeit für einen Office 365 Administrator einsehbar. Diese Berichte sind für jene Office 365 Abo’s abrufbar, wo zumindest eine Exchange Online Lizenz enthalten ist.