blog.atwork.at

news and know-how about microsoft, technology, cloud and more.

Der Weg zur kostenfreien MSDN Azure Test-Subscription mit einem Microsoft Partner Account-Teil 1

Friday, April 18, 2014 3:29 PM Toni Pohl
Als Microsoft Partner erhält ein Unternehmen Zugang zu Microsoft MSDN und ein Testkontingent für Microsoft Azure. Nachdem dieser Vorgang einige Schritte erfordert und vielleicht nicht immer ganz klar ist, habe ich hier eine Schritt-für-Schritt Anleitung hinterlegt, beginnend vom Zuordnen eines Microsoft Kontos im Partner-Web bis zum Hinzufügen eines MSDN-Abonnements.
General | Azure | Microsoft
mehr

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

Tuesday, April 15, 2014 10:04 AM Martina Grom
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.
Azure | Cloud | Microsoft | Security
mehr

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

Tuesday, April 1, 2014 5:00 PM Toni Pohl
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.
Cloud | Developer | English | Event | Exchange | Microsoft | MVP | Office365 | SharePoint | Visual Studio | Azure
mehr

Wie Sie mit Hilfe von IdFix Fehler im Active Directory finden und beheben

Thursday, January 23, 2014 9:34 AM Martina Grom
Gerade mit dem neuen Windows Azure Active Directory Sync Tool ist es besonders einfach, ein lokales Active Directory nach Office 365 zu synchronisieren. Dabei kann man seit einiger Zeit auch die Kennwörter des Active Directories mitsynchronisieren, was bei vielen Unternehmen die Komplexität einer ADFS Infrastruktur nicht mehr erforderlich macht und hilft, trotz zweier Identitäten nur ein Kennwort zu haben. Damit gibt es fast ein SSO Erlebnis da sich die Benutzer mit ihrem gewohnten Kennwort anmelden können, ohne SSO zu sein. Eine kurze Erklärung am Rande, da dies oft missverstanden wird: Es wird nicht das Kennwort aus dem AD im Klartext synchronisiert sondern nur der HASH Wert des Kennwortes, der danach noch einmal, bevor die gesicherte Datenübertragung erfolgt, mit einem SHA256 Algorithmus gehashed wird. Active Directory Domain Services speichert Kennwörter im Active Directory mit diesem doppelt gehashten Wert. Dieser kann nicht für ein Login verwendet werden und kann auch nicht in ein Kennwort "zurückgerechnet" werden, um sich anzumelden. In Windows Azure Active Directory gelten die gleichen Regeln: kein "zurückrechnen". Das Kennwort wird zu keiner Zeit im Klartext in das Windows Azure Active Directory und damit zu Office 365 übertragen. Azure Active Directory Sync erfordert außerdem nur einen einzigen Server mit Outbound Internet Verbindung, weitere Firewall Einstellungen sind hier nicht nötig (Inbound). Sobald WAADS installiert und konfiguriert ist, erhält ein Administrator dann während des Syncs Informationen, ob es Fehler in der Synchronisierung gibt. Diese gilt es natürlich auszubessern. Mit IdFixIdFix steht ein Tool zur Verfügung, das Ihnen bei der Behebung genau dieser Fehler helfen kann. IdFix fragt Ihr Directory mit Ldap ab und ermittelt mögliche Fehler - und bessert diese auf Wunsch aus. Zuerst einmal laden Sie IdFix herunter und entpacken die Exe. Dann führen Sie IdFix aus - mit einem Account, welches in Ihrem AD lesen UND schreiben darf. Sobald Sie dann auf den Punkt Query klicken, erhalten Sie nach einiger Zeit das Abfrageergebnis. Dieses können Sie exportieren, um die Details anzusehen. Über den Punkt Action können Sie dann Korrekturen vornehmen. Hierbei haben Sie mehrere Optionen: EDIT: Informationen aus der Update Spalte werden verwendet, um die Attribute zu verändern, die einen Fehler verursachen. Ein neuer Wert kann ebenfalls in die Update Spalte manuell eingegeben werden. REMOVE: in diesem Fall wird das falsche Attribut aus dem Objekt entfernt, z.B. bei einer doppelten ProxyAddress. COMPLETE: Der Wert ist ok und soll nicht geändert werden. Wenn z.B. zwei Benutzer die gleiche Proxy Adresse haben, markieren Sie einen der beiden als COMPLETE und den anderen als REMOVE. UNDO: Dieser Wert wird nur angezeigt, wenn Sie ein bereits vorhandenes Update geladen haben. Damit können Sie den letzten Befehl rückgängig machen. FAIL: Dieser Wert wird nur dann angezeigt, wenn ein Wert einen Konflikt erzeugt. Sobald Sie die gewünschten Änderungen mit APPLY durchgeführt haben, verschwinden die angezeigten Fehler nach und nach. Sie haben ebenfalls die Möglichkeit, die Werte zuerst zu kontrollieren indem Sie einen Export in ein CSV machen. Dies passiert über den Punkt Export. Beispiel: der Error-Eintrag Topleveldomain im Proxyaddresses Feld sagt aus, dass eine interne Domain nicht gesynct wird. Hier könnten Sie den Eintrag über REMOVE aus den Proxyaddresses entfernen. Sie sehen, mit diesem einfachen Tool kann Ihr Active Direcory schnell für die Directory Snychronisation vorbereitet werden.
Microsoft | Office365 | Cloud | Azure
mehr