saschg

NCM auf die Länge

Posted by saschg Mar 30, 2017

Hallo!

 

Wie versprochen geht es heute mit NCM weiter – aber heute werden wir aktiv!

 

Fangen wir mit etwas einfachem an – dem Ändern einer Konfiguration mittels Vorlage.
Warum wollen wir sowas tun?


Es spart Zeit, da wir Änderungen auf hunderten von Geräten gleichzeitig durchführen können.
Wir können es auch als Aufgabe ansetzen und ausserhalb der Geschäftszeiten durchführen lassen, ohne daneben stehen zu müssen. Und es minimiert eine Fehlerquelle: Unsere Finger in der CLI

 

Also, Config Change Templates.

Es gibt ein paar die direkt mit NCM ausgeliefert werden, ebenso die Integration in die Community hier

Aber natürlich auch direkt aus NCM heraus

Ich bin gerade wenig abenteuerlich und habe ohnehin Hut und Peitsche verlegt, daher nehme ich einfach mal das Ding hier:

02.png

Oben klicke ich auf „Define…“

Wähle meinen Freund den Catalyst aus

04.png

 

Erstelle ein Banner

05.png

 

Wie jetzt Minuten…ich habe doch keine Zeit…

06.png

 

Na gut das ging schnell. Vorschau verfügbar:

07.png

 

NCM ist noch nicht übersetzt. Ich bin gespannt, wie das hier später auf Deutsch aussehen wird.

08.png

Keine Beschwerden – gut:

09.png

 

Test mit dem SSH Client meines Vertrauens:

10.png

Prima!

Aber wieder ein paar Schritte zurück. Ich wähle noch einmal die Vorlage aus aber dieses Mal klicke ich oben auf „Advanced…“

11.png

 

Jetzt sehe ich tatsächlich die Vorlage. Oben werden zuerst die Variablen ausformuliert:

12.png

 

Und in der unteren Hälfte sehen wir Cisco Commands

13.png

 

Tipp: Schaut euch an, wie die verschiedenen Vorlagen gebastelt sind. Ist gutes Lernmaterial und meiner Meinung nach interessanter als das Lesen des Handbuches.

Ich wechsle in den Bereich Configuration Management und ziehe mir eine neue Config

14.png

 

Klicke auf „compare“ und vergleiche die letzte Running gegen die neue

15.png

 

Jetzt bin ich natürlich kein Kunstbanause und mag das Banner überhaupt nicht!
Also klicke ich Upload und wähle die vorherige Version um den alten Zustand wieder aktiv zu setzen:

16.png

 

 

Das nächste Thema: Compliances. Zu Deutsch: Konformitäten. Was für ein Wort!

NCM bringt von Haus aus Vorlagen für ein paar mehr oder weniger bekannte Namen wie PCI, SOX oder auch HIPAA.

Als Beispiel PCI; es gibt 12 verschiedene Reporte

17.png

 

Ich aktivere einmal Nr 2, dazu klicke ich auf Manage Policies, Enable und „Update“.

Hinweis: Wir setzen hier auf den Informationen aus den beiden Jobs aus, die wir im letzten Posting definiert hatten.

18.png

Schliesslich schaue ich mir den Bericht an

19.png

Der Klick auf ein Ausrufezeichen ergibt Details

20.png

 

Wie funktioniert so etwas nun?

 

Die Dinge sind verschachtelt. Ein Report (PCI) enthält eine oder mehrere Policies (Vendor Defaults) welche eine oder mehrere Regeln enthalten (VTY Zugriff).

Die Regel von oben sieht so aus

21.png

 

Wenn wir also im Terminal nicht SSH in/out finden, ist das für uns bzw PCI ein Verstoss.

Diese Regel sieht lediglich eine Benachrichtigung vor – langweilig!
Was ich aber auch einsetzen kann, sind automatische Gegenmassnahmen.

22.png

Im Beispiel oben z.B. „no telnet“, „no feature telnet“ bei NX-OS oder was auch immer wir gerade brauchen.

Ihr merkt schon – das Regelwerk ist vollkommen frei gestaltbar, ich kann meine eigenen Regeln zusammenfassen und einsetzen.

Um Arbeit zu sparen schlage ich jedoch vor, die bestehenden Regeln zu sondieren und „auszuschlachten“, was sinnvoll erscheint.

 

 

Nun schliesslich etwas ganz Neues – IOS Firmware Updates in Version 7.6.

Was sticht zuerst ins Auge: Icons. In Farbe. Und bunt.

23.png

Ich gebe der Operation einen Namen und wähle die für meinen Switch passende Vorlage aus:

24.png

Nächster Schritt – das Auswählen des neuen Images.

25.png

 

Das Repository bestimmt ihr natürlich vorab, üblicherweise ein Netzwerkpfad.
Und nein, wir liefern die binär Dateien nicht mit NCM. Dazu geht ihr bitte mit eurem CCO Konto auf die Webseite des Herstellers.

Ziele auswählen, der Catalyst ist immer noch mein Freund – nur für wie lange noch?!

26.png

Das hier dauert ein wenig:

27.png

Na klar, ich reviewe:

28.png

 

Oben können wir durch die Kommunikation scrollen, darunter sehen wir die Warnung für unzureichenden Speicherplatz.

29.png

Alle Optionen hier sind vorausgewählt, ich lasse es einmal dabei:

30.png

 

Die Vorschau zeigt mir, was gleich passieren wird:

31.png

 

Das Backup des aktuellen Images wird übrigens in einem Unterordner im Repository erstellt, sortiert nach Gerätenamen sowie Datum.

Klicken wir jetzt wirklich auf weiter?!

32.png

Klar, es gibt das hier:

33.png

Und auch: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-2950-series-switches/41845-192.html

Aber, aber…egal, ich klicke auf weiter. Und weiter.

34.png

 

YES eingeben ist wie das Bestätigen des Lesens irgendwelcher AGB.

35.png

 

Trommelwirbel setzt ein…oder Fahrstuhlmusik...

36.png

 

Reicht die Zeit noch, um sich nach einem neuen Job umzuschauen für den Fall, dass der Switch abraucht?

37.png

Zu spät!

Ich habe beim Prozess keinen automatischen Neustart angewählt, das mache ich nun manuell:

38.png

Übrigens: Niemals hinter einem Switch stehen während dieser neustartet. Ruiniert die Frisur.

 

Gefühlte Tage später und zwei graue Haare reicher:

39.png

 

Mein Freund der Switch und ich brauchen jetzt ein Bier!

As I'm sure you’re now well aware of, the AWS® outage, earlier this month, was caused by simple human error, where an unfortunate soul ran a command without fully understanding its consequences. As sqlrockstar pointed out in his post on the topic Lessons Learned From the AWS Outage, PowerShell's creator, Jeffrey Snover, actually built such functionality to help mitigate such errors into PowerShell itself. So, I thought it would be a good opportunity to look at that functionality in a more detailed, practical manner. In particular, I want to look at using -Whatif and -Confirm within functions.

 

To examine the topic further, I've added a real-world example—in this case, the "Remove-OrionNode" function from the PowerOrion module.

Import-Module-Name"C:\projects\OrionSDK\Samples\PowerShell\PowerOrion\PowerOrion.psm1"-Force
$swis = Connect-Swis 192.168.100.2 -UserName admin -password ''
Remove-OrionNode -SwisConnection $swis -IPAddress '192.168.100.2' -WhatIf


 What if: Performing the operation "Removing Object" on target "swis://192.168.100.2/Orion/Orion.Nodes/NodeID=1"

 

If I called the above three lines, but without the "-whatif" parameter in the final line, the code would simply execute, and the node referenced by "NodeID=1" would be deleted. But as that particular object wasn't actually targeted within the function call—rather, the IP "192.168.0.2" is—is that the node the user expected, or was a different node expected? By simply adding the -whatif parameter, the user can now have a very good understanding of what will happen before a major change is affected.

 

Similarly, if we want to confirm such a change, we can utilise the "-confirm" parameter, providing the user a safeguard, to confirm/reject such changes.

 

Confirm Remove Node.png

 

How to Implement

 

Fortunately, PowerShell provides an excellent framework to allow such expanded functionality. By adding the "CmdletBinding" attribute to your advanced functions, your PowerShell can now behave like compiled cmdlets. Without any other parameters, this is enough to allow passing "-verbose" and "-debug" to your functions. In particular, the "SupportsShouldProcess" allows the -WhatIf and -Confirm functionality we are looking to achieve.

 

For more information on the topic you can run the following command:

 

get-help about_Functions_CmdletBindingAttribute

 

 

However, for a more practical inspection, we will analyze the function below. To enable the functionality, we simply place it just after the function name is defined:

 

[CmdletBinding(SupportsShouldProcess=$True)]
function Remove-OrionNode
  {

    ...
}

 

However, we then call the code by wrapping actual code that makes the edits in an "if" statement, which calls " $PSCmdlet.ShouldProcess("$uri","Removing Object")". So that is the actual logic that calculates what object is under scope, as well as provides the textoutput, which can be seen in the previous screenshot.

 

Conclusion

By leveraging PowerShell's native safeguard functions, you can now easily add a level of robustness, helping to prevent unintended consequences when running your scripts. I'd be interested to hear if you were already doing something similar in your script. If you have any interesting input on the topic, please share in the comments below.

saschg

NCM auf die Schnelle

Posted by saschg Mar 22, 2017

Tach Zusammen,

 

Wir haben hier gesehen wie man ein Orion Produkt installiert und hier sind wir durch den Prozess des Einpflegens von Nodes gegangen.

Heute gehen wir mal mit einem Produkt etwas weiter in die Tiefe – dem Network Configuration Manager.

NCM wirkt beim ersten Ansehen als komplex, basierend auf den Optionen die zur Verfügung stehen. Ich hatte schon oft Gespräche mit Kunden nach dem Motto „Lieber Herr Solarwinds, das ist zwar ganz nett aber wo bitte soll ich denn anfangen?“

 

Nun, zuerst müssen Nodes in das System.
Zusätzlich zu meinem „..Zeugs“ Post wird noch ein weiterer Schritt benötigt:

01.png

Im Connection Profile geben wir die Zugangsdaten ein. Bevorzugt natürlich SSH anstatt Telnet.

02.png

Was kann hier schiefgehen?

 

Falsche Zugangsdaten, eine ACL die blockiert, oder aber ein Kommunikationsproblem zwischen NCM und dem Gerät.

Der erste logische Schritt bei Problemen ist von der NCM VM heraus eine putty Verbindung zum Gerät aufzubauen. Dadurch können wir Probleme mit den Zugangsdaten oder dem Netzwerk direkt ausschliessen.

Die NCM interne Stolperfalle habe ich in meinem Screenshot – dort ist ein Catalyst mit dem keine Probleme zu erwarten sind. Ich habe jedoch schon einige Geräte gesehen bei denen „SSH Auto“ fehlschlägt weil die Verschlüsselung nicht korrekt übermittelt wird.

Im Zweifelsfalle direkt Version 1 oder 2 manuell auswählen um sicher zu gehen.

 

Ein anderes Thema sind die Device Templates.

03.png

 

NCM nutzt Vorlagen um die Verbindung aufzubauen und wird mit einer langen Liste ausgeliefert die durch unsere Community erweitert wird.

Glücklicherweise steht uns das auch direkt aus dem Produkt heraus zur Verfügung und kann kostenlos importiert werden:

 

04.png

 

Wenn NCM out of the box also keine passende Vorlage mitbringt ist der nächste Schritt die Community.

Dort finden wir dann auch Dinge wie z.B. vyos. Kennt ihr das eigentlich? Grossartige freeware, vielleicht stelle ich das irgendwann mal im Detail vor.

 

Und wenn auch dort keine Vorlage ist? Dann erstellen wir uns eine.

 

Settings --> All Settings --> Advanced/Device Templates:

05.png

 

Der „interactive wizard“ ist die erste Methode –einfach den Schritten folgen und die Daten ergänzen bzw anpassen.

 

06.png

 

Profis werden vermutlich direkt den XML Editor nutzen. Geht schneller, aber man sollte schon die eine oder andere Vorlage gesehen haben.

 

Wenn es beim Erstellen Probleme gibt haben wir ein nettes Feature unter à Advanced/Advanced Settings:

07.png

Wenn die Box ausgewählt wird, schreibt NCM ein Log unter ProgramData – Achtung; das ist ein verstecktes Verzeichnis!

 

08.png

 

Das Log erläutert Schritt für Schritt was passiert und was das Gerät zurückgibt und hilft bei der Fehlersuche.

 

Okay, Geräte sind drin. Jetzt erst einmal einen Kaffee. Das geht bei mir ganz bequem vom Mobiltelefon aus:

 

09.png

 

Im nächsten Schritt setzen wir Aufgaben an, welche die Konfigurationen abholen. Das ist simpel.

Klickt auf die Jobs – zwei davon sind für uns gerade interessant; Nightly Config und Inventory.

 

10.png

 

Gehen wir mal durch den Config-Job:

Schritt 1 – wann, wie oft, wie lange: Natürlich ausserhalb der Geschäftszeiten.

11.png

 

Schritt 2 – Ziele bzw Quellen auswählen: Alle beinhaltet alle Nodes die in NCM eingepflegt sind.

12.png

 

Schritt 3 – Email? Vielleicht! Aber das Log sollte immer geschrieben werden.

 

13.png

 

Schritt 4 – okay jetzt müssen wir aufpassen. Hier mein Vorschlag:

14.png

 

Wir teilen dem Job hier mit, beide Configs zu sammeln sofern vorhanden, aber nur wenn es eine Änderung gab. Das sorgt dafür, dass das Repository nicht mit den gleichen Configs zugemüllt wird.

Aber es mag durchaus Situationen geben wo dies gewünscht ist, wenn z.B. eine Richtlinie lückenlose Backups erfordert.

Die Schalter unten sind für die Baselines. Die haben wir aber jetzt noch nicht angelegt und ignorieren dies grosszügig!

 

Zweimal „next“ und das war‘s!

 

Schauen wir noch kurz in den anderen Job hinein um das Thema abzuschließen.

Bei der Inventarisierung sind die ersten drei Schritte gleich. Ich schlage vor, den Job ein paar Minuten später durchlaufen zu lassen – abhängig von der Größe eurer Infrastruktur.

In Schritt 4 wählt ihr einfach was für euch passt. Hier nur ein kleiner Auszug:

15.png

Eine kurze Anmerkung: Weiter unten in der Liste findet sich auch „Windows Server“. Dies wurde von einer vorherigen NCM Version geerbt und wird von uns nicht länger weiterentwickelt. Hier einfach ignorieren. Wer an dieser Funktion interessiert ist schaut sich vielleicht einmal den Solarwinds Server & Application Monitor an.

 

Zurück zu der Job Liste bitte, dann einmal die beiden Jobs einzeln anklicken und „Start Job“ um die ersten Daten zu bekommen:

 

16.png

 

 

Hat alles geklappt? Prima, NCM ist nun einsatzbereit. Viele der Charts zeigen natürlich Änderungen an und füllen sich erst nachdem zweiten Durchlauf eines Jobs.

Spielt ein bisschen herum. Nächste Woche (wenn alles klappt) führe ich einmal durch die Compliancepolicies und wir stellen etwas Unsinn an.

 

Gut bis dahin!

saschg

Agents!

Posted by saschg Mar 10, 2017

Es war einmal… vor ein paar Jahren sagten wir “agentless monitoring”. Mittlerweile hat Solarwinds dreieinhalb Agents!

Orion (NPM/SAM), Patch, LEM und die Player-Komponente vom Web Performance Monitor.

 

Schauen wir uns mal die Details an.

Zuerst ein Foto vom Orion Agent, aufgenommen aus einem Versteck mitten in der Nacht:

1.png

Dann habe ich ihn um die Mittagszeit auf Windows erwischt, man beachte den Hut:

2.png

 

Grundsätzlich stimmt die Aussage von „agentless monitoring“ immer noch, keine Sorge!

Man kann bei jedem einzelnen System auswählen, ob ich die native Methode bevorzuge (WMI/SNMP) oder eben den Agenten. Beide haben durchaus valide Einsatzszenarien.

In den meisten Fällen wird nach wie vor WMI das Mittel der Wahl sein – ich muss nichts installieren, nicht konfigurieren und es läuft ohne Probleme meistens problemlos.

In der Praxis gibt es jedoch zwei Situationen die hier Kopfschmerzen bereiten können.

 

Zum einen das Netzwerk! ES IST IMMER DAS NETZWERK! (sorry, den konnte ich mir nicht verkneifen).
WMI nutzt dynamische Ports und unter Umständen nicht wenige davon. Kann in manchen Umgebungen ein Alptraum sein. Mehr Info hier:

https://thwack.solarwinds.com/community/solarwinds-community/product-blog/blog/2013/01/08/wmi-portapocalypse

 

Wenn wir uns dagegen den Agenten anschauen:

3.png

 

 

Darüber hinaus: Steht irgendwo ein Proxy im Weg, habe ich vielleicht überlappende IP Bereiche? All das legt noch eine weitere Schicht Komplexität oben drauf, die ich mit dem Agenten umgehen bzw vereinfachen kann.

 

Die andere Situation die ich hin und wieder erlebe ist eher politischer Natur.

Zum Überwachen einer Windowsbox benötigt Orion normalerweise einen lokalen Admin. Ja, wir haben irgendwo die Schritte um ein solches Konto zu beschränken, aber trotzdem ist es in manchen Umgebungen einfach nicht tragbar.

Hier läuft der Agent als Dienst und ich habe keine administrativen Credentials irgendwo im Solarwinds-System.

Ebenso ist sämtliche Kommunikation zwischen Orion <> Agent verschlüsselt.

 

Bestimmte Dinge werden auch erst durch den Agent ermöglicht:

4.png

 

 

Es gibt verschiedene Deployment Methoden, die simpelste einfach beim Anlegen einer einzelnen Node:

5.png

Weitere Details hier:

http://www.solarwinds.com/documentation/en/flarehelp/sam/content/samagorionagentdeployagentorion.htm

Der Agent dient jedoch ebenso zwei speziellen Szenarien und in diesen wird er zwingend benötigt; Quality of Experience sowie NetPath. Glücklicherweise ist das das gleiche Stück Software und es müssen nicht drei verschiedene Pakete bereitgestellt werden.

Ich kann zum Beispiel den Agent direkt aus einer frischen NetPath Operation remote installieren:

 

6.png

 

 

Weitere Informationen zu dem Thema findet hier:
http://www.solarwinds.com/documentation/en/flarehelp/sam/content/core-agent-requirements-sw476.htm

 

Der nächste bitte! Ahja, der Patch Manager Agent.

 

Tatsächlich braucht man hier gar nicht so viele Worte verlieren da der Ansatz sowie Einsatz ähnlich ist.

Unser Patch Manager nutzt normalerweise WUAU (tolle Abkürzung, oder?) sowie WMI zur Kommunikation.

In komplexeren Umgebungen oder auch nur einer einzelnen DMZ kann es schwierig werden und der Agent hilft.

 

Aufgepasst: Der Agent ist hier kein Ersatz wie oben bei Orion. Der Agent dient dem Aufbau der Kommunikation.

Sämtliche Aktionen werden lokal auf der Maschine wieder an den WUAU abgegeben.

 

Deployment? Folgt mir unauffällig hierhin:

https://support.solarwinds.com/Success_Center/Patch_Manager/Patch_Manager_2.1.3_Administrator_Guide/0B0/020

 

Interessanter ist der LEM Agent.

Log & Event Manager bezieht Daten aus dem Netzwerk mittels Syslogs und von Servern/Workstations mittels Agents und hier gibt es diesmal keine Alternative.

Primär sorgt der Agent dafür, dass jegliche Logs vom Zielsystem zur LEM Appliance transportiert werden.

Das ist eine Aufgabe mit mehreren Schritten – z.B. dem Auslesen einer spezifischen Logdatei auf dem entfernten Dateisystem, dem Komprimieren und Verschlüsseln der Daten und schliesslich dem Versenden.

7.jpg

 

Der Agent erlaubt auch weitere Features wie z.B. File Integrity Monitoring a.k.a. „Wer hat schon wieder die Excel Tabelle vom Share verschoben?“ und bringt Aktionen wie dem virtuellen Auswerfen von unerwünschten USB Geräten oder dem Verschieben von Benutzern in weniger privilegierte AD Gruppen, oder dem Herunterfahren des Rechners.

 

Ich könnte an dieser Stelle sagen wieviel Spass es macht die Workstation eines Kollegen herunterzufahren, aber sowas würde ich natürlich nie tun!

 

Die Agents gibt es für viele Betriebssysteme und das Deployment ist wie gehabt recht simpel:

8.png

Der letzte im Bunde – der halbe Agent!

Web Performance Monitor nutzt drei verschiedene Komponenten zum Aufnehmen, Kontrollieren und Abspielen von Schritten. Die Abspielkomponente („Player“ - wer hätte das gedacht) wird irgendwo hingesetzt um Schritte auf Webapplikationen durchzuführen.

9.png

Der Player ist etwas grösser sowohl als Datei als auch in den Anforderungen als die obigen Agents und wird üblicherweise manuell an einzelnen strategischen Standorten abgesetzt wie entfernten Niederlassungen oder vielleicht in der Cloud.

 

10.png

 

Wie schön wäre es jetzt, wenn man die Funktionen des Players in den Orion Agent integrieren könnte?

Das wäre doch einmal eine tolle Idee. Ich muss plötzlich weg, das Vorschlagsforum ruft!

In this week’s post, we will look at the steps needed to create a PowerShell® module containing the functions written in previous posts. While functions are the keystones in code reuse, encompassing them within modules allows the most flexible and easy ways to share code between users and machines.

 

At its simplest, a PowerShell module can be made by creating a .PSM1 file, which has the same name of your module, and placing your functions within. That file is then itself placed in a folder—again, named after your module.

 

Function Write-Hello{
     write-host "Hello World"
}

For example, if I want to create a module called “MyModule,” to share with others, and within that module I want to share with others, I would simply create a folder called “MyModule,” and within that folder a text file called "MyModule.psm1". Next, we simply copy our function(s) into the file.

 

While modules can be loaded from anywhere, the best practice is to load them in to $home\Documents\WindowsPowerShell\Modules. (If you want to use a non-listed location, simply use the “Import-Module” cmdlet.)

 

However, you can check a full list of folders by running:

 

get-item env:psmodulepath | select value -ExpandProperty value

 

If we do a quick “get-module –listavailable,” we can now see our module is listed.

 

get-module -listavailable.png

 

Since it's loaded now into the session, any cmdlets within that module can now be called, simply by calling the relevant command name. We can verify our example by listing all commands that begin with the "write" verb.

 

get-command -verb write

 

get-command -verb write.jpg

 

One point worth noting in the previous examples, is that we can see in the screenshots that the module version is listed as “0.0.” If we want to add metadata to our modules, such as versions, license info, authors, etc., we can achieve this by adding a manifest file (a .psd1 file, which contains a hashtable with all the values). Of course, as with most things PowerShell, there's a cmdlet to help!

 

get-help New-ModuleManifest

 

Here is the example I used to build my manifest:

 

$guid = [guid]::NewGuid()
New-ModuleManifest -path .\MyModule\MyModule.psd1 -Guid $guid -Author 'Michael Halpin' -Description "Demo Module" -ModuleVersion 0.1

These are the basic steps that I used when creating the PowerOrion module. If you have done any work in creating your own modules, feel free to share those in the comments below.

Aloha!

 

Wie hier angekündigt waren wir Ende Februar auf der Messe in Berlin. Leider komme ich erst jetzt dazu, ein paar Worte zu schreiben.

 

Wir waren kein „Gold Exhibitor“, also musste ich mit Silberbesteck essen aber wir wollen mal nicht kleinlich sein!

Trotzdem waren wir „all over the place“ wie man im Englischen so schön sagt und wir kamen mit dieser Nachricht zur Messe:

http://globenewswire.com/news-release/2017/01/10/904698/0/en/SolarWinds-Recognized-as-Market-Leader-in-Network-Management-Software.html

 

Unser Stand war recht gross, wir sind mit sechs Workstations angereist (letztes Jahr waren es vier) und waren knapp 10 Personen. Darunter auch Patrick und Leon die erfolgreich zwei Worte Deutsch gelernt haben!
Wir sind 1000 T-Shirts, 1000 Mützen und 300 Rucksäcke losgeworden.

 

Ich hatte eine kleine VM mitgebracht um NetPath live vom Stand laufen zu lassen und dabei festgestellt, dass der Pfad zu www.google.com deutlich länger war als zu www.ciscco.com. Ein Schelm, wer Böses dabei denkt…

 

Da ich meistens zu beschäftigt war habe ich kein wirklich gutes Foto aber hier ist eines von etwa 20 Minuten nach offiziellem Ende am zweiten Abend als schon nicht mehr so viel los war:

IMG_0995.JPG

 

 

Ich habe mit vielen Kunden geredet die vorbeikamen und unsere neuen Features sehen wollten wie die PerfStack Übersicht, Meraki und Cloudmonitoring oder auch das neue IOS Upgrade GUI.

 

Sehr positiv war der Austausch – ich habe viele Dinge aus eurer täglichen Praxis gelernt die mir neu waren, aber auch ich konnte hin und wieder Tipps geben wie bestimmte Dinge einfach(er) zu lösen sind.

Ebenso noch einmal speziellen Dank an die drei Herren aus Frankfurt die mir Kaffee und Brötchen vorbeigebracht haben als ich kurz vor dem Verhungern war!

 

Insgesamt war die Show deutlich grösser als im letzten Jahr mit zwei weiteren Hallen.

Leider hatte ich nicht viel Gelegenheit selbst einmal durch die Hallen zu gehen. Soweit ich es sehen konnte waren viele Anbieter von Deep Packet Inspection anwesend welche die Technologie mittlerweile für die verschiedensten Szenarien nutzen.

SDN, letztes Jahr noch das Thema, war in diesem Jahr nicht mehr ganz so präsent, aber IOT war dann doch in aller Munde sowohl von Cisco selbst als auch von einigen Partnern. Ich bin mittlerweile sehr daran interessiert, auch über die Haarbürste hinaus!

Das Highlight war natürlich die Party am Donnerstagabend:

 

IMG_1006.JPG

 

Oh und ich hatte Schnitzel. Viele, viele Schnitzel

 

Nächstes Jahr geht es nach Barcelona!

 

Bis die Tage,

Sascha

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.