Archive for the ‘Azure’ Category

Microsoft Schwachmaten mal wieder at it’s best! Tschüss Einmalcodes

26 November 2016

Wenn ich auf fremden Rechnern unterwegs bin und mit Microsoft Diensten Kontakt aufnehme, dann melde ich mich grundsätzlich mittels des sogenannten Microsoft Einmalcodes an. Dabei gebe ich meine Handynummer an und erhalte dann zum Login eine Nummer per SMS. Dies ist der sogenannte Einmalcode oder Single Use Code.

Scheinbar ist diese Funktion seit kurzem nicht mehr überall verfügbar. So lassen sich einzelne Anfragen im Netz dazu finden.

http://www.win-10-forum.de/outlook-com/20869-anmeldung-einmalcode-verschwunden.html

http://www.gutefrage.net/frage/anmeldung-mit-einmalcode-verschwunden-kein-login-mit-sms

Es gab aber nirgends eine Info zu finden, dass die Funktion eingestellt wurde. In der Knowledge Base gibt es diesen Artikel vom Juni 2016: https://support.microsoft.com/en-us/help/10552/microsoft-account-sign-in-single-use-code.

Fakt ist nur, dass aktuell der Einmalcode nicht verfügbar ist und wenn obige Links stimmen, fehlt die Funktion seit Anfang Oktober 2016.

Nach einigem Probieren bin ich dann aber doch noch fündig geworden. Nachdem ich https://account.activedirectory.windowsazure.com aufgerufen hatte, konnte ich mich mittels Einmalcode anmelden. Anschließend konnte ich dann Outlook.com aufrufen und war bereits angemeldet.

DANKE Microsoft für diesen tollen Schritt, damit habt ihr mal wieder deutlich Eure Bilanz aufpoliert und könnt wieder mehr Kohle sparen. Ihr habt wieder einmal mehr den Benutzern die Arschkarte gezeigt! Weiter so! Wer braucht schon Sicherheit, man hat ja den SDL…

Werbeanzeigen

Probleme mit Installation von Microsoft Azure Powershell

21 Oktober 2016

Nachdem nach der Ignite Version 3.0.0 der Microsoft Azure Powershell Module erschienen ist https://azure.microsoft.com/en-us/blog/azure-powershell-300/, dachte ich ich versuche nochmal zwei Rechner auf diese Version zu aktualisieren, die davor sich verweigert haben. Doch leider wie seither ohne Erfolg. Ich hätte hier jetzt die Meldungen aufgezeigt, doch dank Windows 10 unermüdlichen Neustarts sind diese verloren gegangen. Deshalb hier nur der Verweis auf die Lösung.

Zunächst wurde versucht die betreffenden Module wie hier beschrieben zu installieren: https://github.com/PowerShell/PowerShell/issues/1874#issuecomment-241170545. Klappte jedoch leider nicht. Danach weitergesucht und am Ende sagte hier jemand was von Verzeichnissen löschen: https://powershell.org/forums/topic/unable-to-install-module-azurerm/.

Tatsächlich, nachdem in den Verzeichnissen

%ProgramFiles%\WindowsPowerShell\Modules folder
%ProgramFiles(x86)%\Microsoft SDKs\Azure\PowerShell

alles gelöscht wurde, was nach Azure roch, funktionierte danach endlich das Install-Module AzureRM.

Source auf Github: https://github.com/Azure/azure-powershell

Sinnvolle Größen von virtuellen Maschinen in Verbindung mit Azure

5 Mai 2016

Wenn man mit virtuellen Maschinen in Azure arbeitet, gibt es mittlerweile eine Unzahl von Maschinen zur Auswahl. Für Westeuropa gibt es aktuell 63 verschiedene Konstellationen.

(Get-AzureRmVMSize -Location westeurope).length

Wenn man einen Überblick über die Welt haben möchte, dann kann man dies mittels diesem Aufruf bekommen:

Get-AzureRmLocation| % {$_.DisplayName; (Get-AzureRmVMSize -Location $_.location).length}

East Asia
39
Southeast Asia
49
Central US
49
East US
53
East US 2
49
West US
53
North Central US
35
South Central US
53
North Europe
53
West Europe
63
Japan West
29
Japan East
43
Brazil South
21

Wie sieht nun so ein VMSize-Eintrag aus? Holen wir uns also den ersten Eintrag:

(Get-AzureRmVMSize -Location westeurope)[0]

MaxDataDiskCount     : 1
MemoryInMB           : 768
Name                 : Standard_A0
NumberOfCores        : 1
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 20480

In diesem Artikel interessiert uns nur MemoryInMB und NumberOfCores.

Bei diesen Informationen stellt sich immer auch gleich die Frage nach dem Preis. Leider sind die Azure Billing APIs mit der RateCard-Info immer noch im Preview Status (https://msdn.microsoft.com/en-us/library/azure/mt218998.aspx). Auch gibt es noch keine Powershell-Cmdlets, so dass ich hier auf die normale HTML-Seite mit den Preisen verweise: https://azure.microsoft.com/de-de/pricing/details/virtual-machines/.

Bleiben wir bei West Europe, es gibt also 63 verschiedene VM-Größen. Aber welche Größen machen wirklich Sinn?

Grenzen wir den Zweck der VM ein, da wäre zunächst die Frage zu klären, ob man ein 32-Bit oder 64-Bit Betriebssystem darauf installieren möchte. Rein technisch kann man zwar 32-Bit Betriebssysteme auf VMs mit 12GB Arbeitsspeicher installieren, aber was macht dies für einen Sinn wenn man nur 4GB maximal nutzen kann?

Man kann mittels

Get-AzureRmVMSize -Location westeurope |where { $_.memoryinmb -le 4096  }

nun die in Frage kommenden VMs ermitteln. Zum Zeitpunkt dieses Artikels lieferte die Abfrage 10 Kandidaten: Standard_A0, Standard_A1, Standard_A2, Basic_A0, Basic_A1, Basic_A2, Standard_D1, Standard_D1_v2, Standard_DS1 und Standard_DS1_v2.

Worin unterscheiden sich nun Standard und Basic? Basic sind für Testserver gedacht, schnell hochfahren was ausprobieren und wegwerfen. Wer eine VM braucht die sinnvolle Tätigkeiten erfüllen soll, sollte Standard wählen.

Die Angaben über A,B,D,G usw. geben dann die Kategorie an, welche die VM im Sinne der Performance und Rechnerpower kategorisiert.

In diesem Zusammenhang muss man wissen, dass erst bei der Kategorie D und G SSDs als Festplatten zum Einsatz kommen. Allerdings ist bei SSDs zusätzlich noch wichtig, das diese nur temporär sind, wer dauerhaft den Inhalt der SSDs benötigt, der muss die DS*-Varianten verwenden.

Kommen wir nochmal zurück zum Arbeitsspeicher. Wer z. B. eine VM zum Ausprobieren möchte, wo ein 64-Bit Betriebssystem zum Einsatz kommen kann, der braucht mindestens 2GB an Arbeitsspeicher.

Dieser Aufruf listet alle in Frage kommenden Größen auf:

Get-AzureRmVMSize -Location westeurope |where { $_.memoryinmb -ge 2048  }

Momentan sind es 59 Stück.

Ein weiterer Faktor bei einer VM sind auch die Anzahl der Kerne. Eine schöne Auflistung, was die einzelnen Größen hergeben erhält man z. B. so:

Get-AzureRmVMSize -Location westeurope|sort numberofcores| Format-Table -GroupBy Numberofcores -Property Name,MemoryInMB, OSDiskSizeInMB, ResourceDiskSizeInMB, MaxDataDiskCount

Man erhält dadurch

   NumberOfCores: 1

Name            MemoryInMB OSDiskSizeInMB ResourceDiskSizeInMB MaxDataDiskCount
—-            ———- ————– ——————– —————-
Standard_D1           3584        1047552                51200                2
Basic_A1              1792        1047552                40960                2
Standard_D1_v2        3584        1047552                51200                2
Standard_DS1_v2       3584        1047552                 7168                2
Standard_DS1          3584        1047552                 7168                2
Basic_A0               768        1047552                20480                1
Standard_A1           1792        1047552                71680                2
Standard_A0            768        1047552                20480                1

   NumberOfCores: 2

Name             MemoryInMB OSDiskSizeInMB ResourceDiskSizeInMB MaxDataDiskCount
—-             ———- ————– ——————– —————-
Standard_G1           28672        1047552               393216                4
Standard_D2_v2         7168        1047552               102400                4
Standard_GS1          28672        1047552                57344                4
Standard_A2            3584        1047552               138240                4
Standard_D11_v2       14336        1047552               102400                4
Standard_DS11         14336        1047552                28672                4
Standard_DS2_v2        7168        1047552                14336                4
Standard_DS11_v2      14336        1047552                28672                4
Standard_DS2           7168        1047552                14336                4
Standard_D11          14336        1047552               102400                4
Standard_D2            7168        1047552               102400                4
Standard_A5           14336        1047552               138240                4
Basic_A2               3584        1047552                61440                4

Weiß man also wie viel Arbeitsspeicher und wie viel Kerne eine VM haben soll, dann kann man hiermit ermitteln was in Frage kommt:

Get-AzureRmVMSize -Location westeurope |where { ($_.memoryinmb -ge 2048 -and $_.memoryinmb -le 4096) -and ($_.numberofcores -le 2) }

MaxDataDiskCount     : 4
MemoryInMB           : 3584
Name                 : Standard_A2
NumberOfCores        : 2
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 138240

MaxDataDiskCount     : 4
MemoryInMB           : 3584
Name                 : Basic_A2
NumberOfCores        : 2
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 61440

MaxDataDiskCount     : 2
MemoryInMB           : 3584
Name                 : Standard_D1
NumberOfCores        : 1
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 51200

MaxDataDiskCount     : 2
MemoryInMB           : 3584
Name                 : Standard_D1_v2
NumberOfCores        : 1
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 51200

MaxDataDiskCount     : 2
MemoryInMB           : 3584
Name                 : Standard_DS1
NumberOfCores        : 1
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 7168

MaxDataDiskCount     : 2
MemoryInMB           : 3584
Name                 : Standard_DS1_v2
NumberOfCores        : 1
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 7168

Obige Liste stellt eine einfache Auswahl an Konfigurationen dar die für einfache Tests mit 64-Bit Betriebssystemen sinnvoll sind. Natürlich kann man mit Cores und Speicher und Performance immer nach oben gehen aber dies ist immer auch eine Frage der Kosten.

Neben den Kosten ist ein weiterer Aspekt der sinnvollen VM Größen im Zusammenhang mit Hyper-V. Wer in Zukunft im Hyper-V virtuelle Maschinen einrichtet, der sollte sich vielleicht auch mit den verfügbaren Größen der Azure VMs auseinandersetzen. Denn wenn später ein Umzug einer VM von Hyper-V nach Azure ansteht, ist es sinnvoll die Grundausrichtung der Hyper-VM bereits an möglichen Azure-VMs vorzunehmen, dann fällt einem der Umzug leichter. Hier hat bereits jemand diesen Gedanken: https://github.com/adbertram/Random-PowerShell-Work/blob/master/Azure/ConvertTo-AzureSize.ps1.

AzureResourceManager und die Hintergründe zu Switch-AzureMode

5 März 2016

Microsofts Azure wird nicht mehr verschwinden. Wer sich effektiv mit Azure beschäftigt, der sollte wie immer per Powershell die Sache angehen. Auf GUIs kann man sich in der Regel nicht verlassen, da diese einer gewissen Mode unterliegen. Aus diesem Grund wird in diesem Blog versucht so gut wie alles per Kommandozeile bzw. Powershell zu regeln.

Blöd nur, wenn sich nun aber die Powershell Cmdlets ebenso ändern und man keinen Plan hat warum, wieso und weshalb. So liest man oft von Switch-AzureMode oder von Azure Resource Manager (ARM). Hier ein Auszug einer Microsoft Dokumentation https://azure.microsoft.com/de-de/documentation/articles/virtual-machines-deploy-rmtemplates-powershell/:

Azure PowerShell ist derzeit in zwei Versionen verfügbar: 1.0 und 0.9.8. Wenn Sie bereits Skripts haben und diese nicht sofort ändern möchten, können Sie weiterhin Version 0.9.8 verwenden. Bei der Verwendung der Version 1.0 sollten Sie Ihre Skripts sorgfältig in Präproduktionsumgebungen testen, bevor Sie sie in der Produktionsumgebung einsetzen, um unerwartete Folgen zu vermeiden.

Cmdlet-Namen der Version 1.0 haben das Muster {Verb}-AzureRm{Nomen}, während Namen der Version 0.9.8 nicht Rm enthalten (z. B. „New-AzureRmResourceGroup“ statt „New-AzureResourceGroup“). Wenn Sie Azure PowerShell 0.9.8 verwenden, müssen Sie zunächst den Ressourcen-Manager-Modus aktivieren, indem Sie den Befehl Switch-AzureMode AzureResourceManager ausführen. Dieser Befehl ist in 1.0 nicht erforderlich.

Das ist alles schön und gut, aber das Web ist voll von alten Beispielen und Code-Snippets und manchmal wäre es ganz gut tiefergehende Infos zum Thema zu erhalten.

Mittlerweile wird auf einen speziellen Artikel verwiesen, der die neuen Möglichkeiten des Ressourcen-Manager-Model anschaulich darlegt: https://azure.microsoft.com/de-de/documentation/articles/resource-manager-deployment-model/

Wenn man zum Thema etwas recherchiert, dann kann man diesen Wiki-Eintrag in Github finden, der geht sehr ausführlich nochmal auf die Hintergrunde ein: https://github.com/Azure/azure-powershell/wiki/Deprecation-of-Switch-AzureMode-in-Azure-PowerShell

Es gibt sogar ein Script, welches automatisch virtuelle Maschinen vom Azure Service Management (ASM) Modell ins Azure Resource Mangement (ARM) Model migriert: https://github.com/fullscale180/asm2arm.

Azure Root Cause Analysis kurz RCA

18 Dezember 2014

Wieder was dazu gelernt. Nach dem gestrigen Artikel https://newyear2006.wordpress.com/2014/12/17/microsoft-azure-ausfall-von-vms-storage-und-weiteren-diensten-am-18-11-2014-bzw-19-11-2014/ bin ich heute noch über den Begriff RCA gestolpert. RCA steht für Root Cause Analysis. Muss man sich merken, denn darüber werden in Zukunft die Azure Probleme dargestellt und näher analysiert. Der Blogeintrag ist gestern irgendwie an mir vorbei oder war noch nicht erschienen. Auf jeden Fall wird alles nochmal deutlich beschrieben: http://azure.microsoft.com/blog/2014/12/17/final-root-cause-analysis-and-improvement-areas-nov-18-azure-storage-service-interruption/

Schade ist nur, dass im Blogeintrag Verbesserungen in der Kommunikation angekündigt werden, ohne konkret eine offizielle Twitteradresse oder alternative Seite zu nennen.

Microsoft Azure Ausfall von VMs, Storage und weiteren Diensten am 18.11.2014 bzw. 19.11.2014

17 Dezember 2014

Alles strebt in die Cloud aber was, wenn die Cloud bockt? Microsofts Azure hatte am 18. bzw. 19.11.2014 einen größeren Ausfall. Dabei ging es nicht um Sekunden, Minuten oder Stunden, nein es ging um teilweise zwei Tage!

Hier der Link zum Blogeintrag: http://azure.microsoft.com/blog/2014/11/19/update-on-azure-storage-service-interruption/. Die Sache war sogar so heftig, dass auch Kunden ohne Wartungsvertrag sich an Microsoft wenden durften.

Hier eine tiefergehende Erläuterung des Vorgangs von Mark Russinovich: http://channel9.msdn.com/posts/Inside-the-Azure-Storage-Outage-of-November-18th.

Was mich an der Sache stört, ist, dass davon auf heise.de nichts zu hören war. Es handelt sich ja nicht um einen kurzen Ausfall sondern war mit zwei Tagen ja schon heftiger. Hier gibt es keinen Newseintrag, wenn man sich den Zeitraum vom 18./19. November anschaut: http://www.heise.de/suche/?q=azure&search_submit=Suchen&rm=search&channel=newsticker. Stellt sich die Frage, hat es keiner bemerkt oder durfte nicht berichtet werden? Andere Newsseiten haben darüber berichtet: http://www.computing.co.uk/ctg/news/2382347/microsoft-azure-suffers-huge-outage-affecting-websites-and-office-365.

Wenn man die Abhängigkeiten von Office365 in Bezug auf Azure kennt, dann sollte doch da eine kritische Masse erreicht worden sein oder nicht? Der Link bei www.computing.co.uk spricht zumindest von Problemen mit Office365.

Auf jeden Fall war das perfide an der Sache, dass die offizielle Azure-Statusseite http://azure.microsoft.com/en-us/status/#current über mind. drei Stunden nicht den tatsächlichen Status der Azure Cloud wiedergegeben hat, sondern dass alles OK wäre. Auch von der Statusseite abhängige APIs waren davon betroffen. Dies wird im Channel9 Video von Mark Russinovich auch nochmal angesprochen. So verstehen sich dann auch die teilweisen harschen Reaktionen im Kommentarbereich des Azure-Blogartikels. Da sind Stunden mit der Fehlersuche verbracht worden, weil die Statusanzeige ja grün war, also liegt das Problem woanders. Aber wo? Und wie kann man als kleine IP-Adresse in der Riesenwolke etwas nachvollziehen bzw. debuggen? Da wird der fähigste Administrator kalt gestellt. Aber das ist unsere Zukunft!

Ich zitiere hier einen Kommentar zum Vorgang, der die Probleme schön illustriert:

ripvannwinklera month ago

Blah blah blah. As others have said:

1. The dashboard inaccurately reflected service status nearly the entire time. A status dashboard should not be a publicity mechanism. If it doesn’t work, fix it. You suck.

2. The outage should have NEVER been rolled out across data centers like it was. I don’t care if infrastructure designs required it – you messed up.

3. I have clients seriously questioning our decision to use Microsoft Azure. It’s upon Microsoft’s head to make this right. BS explanations do nothing to rectify lost time and money or compensate my clients. That falls on me, and as a customer, what reason could I possibly have to trust Azure not to let it happen again in the future?

This is NOT ENOUGH. If you think it is, maybe we should just throw in the Azure towel now?

So ein Ausfall stellt sich dann (gelbe Markierungen von mir) in der Historie der Azurestatusseite als

11/19

Multiple Azure Services – Multiple Regions – Partial Service Interruption

From 19 Nov, 2014 00:52 to 04:40 UTC a subset of customers using Storage, Virtual Machines, SQL Geo-Restore, SQL Import/export, Websites, Azure Search, Azure Cache, Management Portal, Service Bus, Event Hubs, Visual Studio, Machine Learning, HDInsights, Automation, Virtual Network, Stream Analytics, Active Directory, StorSimple, Azure Site Recovery and Azure Backup Services in North Europe, Japan East and Japan West experienced connectivity issues. This incident has now been mitigated.

11/19

Multiple Azure Services – Multiple Regions – Partial Service Interruption

From 19 Nov, 2014 00:52 to 05:10 UTC a subset of customers using Storage, Virtual Machines, SQL Geo-Restore, SQL Import/export, Websites, Azure Search, Azure Cache, Management Portal, Service Bus, Event Hubs, Visual Studio, Machine Learning, HDInsights, Automation, Virtual Network, Stream Analytics, Active Directory, StorSimple, Azure Site Recovery and Azure Backup Services in East US 2, South East Asia and East Asia experienced connectivity issues. This incident has now been mitigated.

11/19

Websites – West Europe – Advisory (Limited Impact)

Starting at 19 Nov 2014 00:52 UTC a subset of customers using Websites in West Europe may have experienced partial service degradation. Engineering reported as mitigated at 11:45AM UTC and continued to monitor until 12:45 PM. This issue is now mitigated.

11/19

Storage – West Europe – Partial Service Interruption

From 19 Nov, 2014 00:52 to 09:15 UTC a subset of customers using Storage in West Europe may have experienced intermittent connectivity issues. This incident has now been mitigated. Further information is available to potentially impacted customers through the Azure Management Portal – http://manage.windowsazure.com

11/19

Application Insights – Multi-Region – Advisory

From 19 Nov 2014 at 01:00 to 12:34 UTC, Application Insights customers using the Azure Preview Portal (portal.azure.com) experienced higher than normal data latency. Please visit the Visual Studio Online blog at http://blogs.msdn.com/b/vsoservice/archive/2014/11/19/issues-with-application-insights-services-11-19-mitigating.aspx for additional information. This incident has now been mitigated.

11/19

Virtual Machines – North Europe – Advisory

This issue is now mitigated for North Europe. We continue to investigate and address issues impacting a limited subset of Virtual Machines customers in West Europe. A subset of customers may see their VMs in continual "Start state”, and limited subset of customers may have difficulty in connecting to their VMs. Potentially impacted customers are advised to continue to visit the Management Portal http://manage.windowsazure.com for more frequent regional details.

usw. dar. Im letzten Statuseintrag sogar ganz ohne Stundenangabe. Der Phantasie darf freien Lauf gelassen werden, wie lange eine VM ausfallen konnte.

Kommen wir zum wahrscheinlich wichtigsten Punkt: Wie kann man die Cloud testen? Ein Datacenter kann man evtl. noch nachbilden und ein Testdatacenter aufbauen um kritische Infrastrukturupdates prüfen zu können. Aber wie kann man die Cloud, welche sich global ausbreitet, testen? Ist doch einfach, man nehme eine zweite Erde für Testzwecke…

Windows Azure Pack Ressourcen

23 November 2014

Die wohl umfassendste Seite zum Thema Windows Azure Pack, es wird kein Thema ausgelassen. Dadurch ist es generell eine der umfassendsten Seite zu Microsoft Azure Themen.

http://social.technet.microsoft.com/wiki/contents/articles/20689.the-windows-azure-pack-wiki-wapack.aspx