Indien zeigt, wie IoT-Initiativen für Deutschland aussehen könnten

In Deutschland sowie in vielen anderen Ländern beobachten wir momentan eine zunehmende Urbanisierung: Menschen zieht es in die Städte, weil sie dort bessere Perspektiven sehen, u.a. mehr Arbeitsplätze oder bessere Gehälter. Nimmt die Bevölkerung in Städten zu, entstehen gleichermaßen auch höhere Kosten für die Stadtverwaltungen. Mehr Bürger erzeugen ein Vielfaches an Müll, die Verkehrsbelastung steigt und der öffentliche Dienst benötigt mehr Mitarbeiter. Städte müssen sich demnach neu aufstellen, um fit für die Zukunft zu sein.
 
In Indien wird diese Umstellung bereits aktiv angegangen: Wir bei Kii haben eine IoT-Initiative mit dem indischen Bundesstaat Andhra Pradesh gestartet. Die dazugehörige Absichtserklärung wurde am 20. Juli 2016 offiziell unterzeichnet.
Das IoT-Projekt umfasst sowohl kurz- als auch langfristige Ziele. Kurzfristig werden wir in den kommenden Monaten und Jahren öffentliche Gebäude mit IoT-Technologien digitalisieren: Pilotobjekt ist der Gebäudekomplex des renommierten International Institute of Digital Technology (IIDT) in der Stadt Tirupati. Des Weiteren sollen in weiteren Städten, aber auch ländlichen Gemeinden, stetig neue Smart City-Pilotprojekte gestartet werden. Neben der Gebäudetechnik werden wir zusätzlich die Bereiche Landwirtschaft und Energie adressieren. Da die örtlichen Bedingungen und Bedürfnisse zwischen Stadt und Land sehr verschieden sind, ist besonders unsere individuelle Beratung vor Ort gefragt.
 
Eigene IoT-Experten ausbilden
Langfrisitg haben wir uns zum Ziel gesetzt, ein IoT-Expertennetzwerk aufzubauen. Ein erster Baustein ist die Errichtung des sogenannten „IoT Centers of Excellence“ (CoE) in den Städten Tirupati und Visakhapatnam, durchgeführt in Kooperation zwischen uns und Andrah Pradesh. In diesen Entwicklungs- und Ausbildungszentren wird eine lokale Community aus IoT-Spezialisten aufgebaut, die zukünftig Innovationen vorantreiben soll. Insbesondere in Tirupati möchten wir die technikaffinen IIDT-Studenten miteinbeziehen. Sie können im CoE Erfahrungen mit IoT-Plattformen, -Technologien, -Best Practices, -Applikationen und -Lösungen von Kii sammeln und eine Expertise entwickeln, die später dem Bundesstaat Andhra Pradesh zugutekommt. Wir bei Kii unterstützen die jungen Entwickler dabei nicht nur technologisch, sondern auch durch Experten vor Ort, die ihr Wissen weitergeben.
 
Nara Chandra Babu Naidu, Chief Minister des Bundesstaates Andhra Pradesh, verdeutlicht die Wichtigkeit der IoT-Kampagne: „Das Internet der Dinge ist der Hauptantreiber unserer digitalen Vision. Um die Digitalisierung unseres Staates voranzubringen, benötigen wir kurz-, aber auch langfristige Initiativen und Ziele. Wir sind froh, dass Kii uns als kompetenter Partner bei beiden Projekten zur Seite steht.“
 
Andhra Pradesh ist ein hervorragendes Beispiel dafür, wie staatliche Organisationen ihre Städte und Gemeinden durch IoT-Initiativen für die Zukunft rüsten können. Solche Initiativen sollten auch deutsche Landesregierungen mit Blick in die Zukunft in ihre Planungen aufnehmen. Denn egal, welchen Bereich man auch analysiert; moderne Technologien wie das Internet of Things könnten viele Städte stark entlasten, z.B. Stromausfälle durch Smart Metering vermeiden oder die Luftverschmutzung durch Smart Pollution-Sensoren eindämmen.
 
Weitere Informationen sind auf der Firmenwebseite von Kii zu finden.

Spezial-Administratorkonten in Active Directory

  • DHCP-Administratoren– Dürfen DHCP-Server in der Domäne verwalten. Die Gruppe wird nach der Installation des ersten DHCP-Servers auf einem Domänencontroller der Domäne erstellt.
  • DHCP-Benutzer– Enthält Benutzerkonten, die lesend auf die Informationen des DHCP-Diensts zugreifen, aber keine Änderungen vornehmen dürfen. Diese Gruppe ist nur für Administratoren und Operatoren, nicht für normale Benutzer oder Computer relevant. Computer, die DHCP-Adressen anfordern, müssen darin nicht aufgenommen werden.
  • DnsAdmins — Diese Gruppe enthält die Administratoren für DNS-Server. Dieser Gruppe sind keine Benutzer zugeordnet. Sie kann verwendet werden, um die Administration von DNS-Servern zu delegieren. Das ist vor allem dann von Bedeutung, wenn die DNS-Infrastruktur eines Unternehmens von Administratoren verwaltet wird, die nicht für die Active Directory-Umgebung zuständig sind. Diese Gruppe wird erst angelegt, wenn ein DNS-Server auf einem Domänencontroller erstellt wurde, der seine Informationen in Active Directory verwaltet.
  • DnsUpdateProxy– In dieser Gruppe befinden sich Computer, die als Proxy für die dynamische Aktualisierung von DNS-Einträgen fungieren können. Diese Gruppe steht nur zur Verfügung, wenn ein Domänencontroller angelegt wird. In diese Gruppe können Sie zum Beispiel DHCP-Server aufnehmen, die dynamische DNS-Einträge für die Clients auf den DNS-Servern erstellen sollen.
  • Richtlinien-Ersteller-Besitzer– Diese Gruppe umfasst die Anwender, die Gruppenrichtlinien für die Domäne erstellen dürfen. Das können Administratoren sein, die sich nur um diese Aufgabe in der Gesamtstruktur kümmern.
  • WINS Users– Diese Gruppe wird angelegt, wenn es einen WINS-Server auf einem der Domänencontroller gibt. In ihr befinden sich die Benutzer, die nur Leserechte auf die WINS-Datenbank haben.

Die Gruppen DnsUpdateProxy, Organisations-Admins, Schema-Admins und DnsAdmins werden in der ersten Domäne, die in einer Gesamtstruktur eingerichtet wird, definiert. Dies ist gleichzeitig die oberste Domäne der ersten Struktur der Gesamtstruktur. Einer Gruppe können Benutzer und Benutzergruppen aus unterschiedlichen Domänen der Struktur hinzugefügt werden.

Standard-Admin-Benutzer in Active Directory

Domänen-Admins– Enthalten die Administratoren, welche die lokale Domäne verwalten und umfassende Rechte in dieser Domäne haben. Ein Administrator ist jeweils nur für eine Domäne zuständig. Wenn Sie mehrere Domänen in einer Gesamtstruktur anlegen, gibt es mehrere Benutzerkonten „Administrator“, die jeweils zu einer Domäne gehören und nur in dieser einen Domäne volle administrative Berechtigungen besitzen. Domänen-Admins haben in einer Domäne umfassendere Rechte als Organisations-Admins

Organisations-Admins– Sind eine spezielle Gruppe von Administratoren, die Berechtigungen für alle Domänen in Active Directory besitzen. Sie haben auf Ebene der Gesamtstruktur die meisten Rechte, aber in einzelnen Domänen haben die Domänen-Admins mehr Rechte. Organisations-Admins gibt es nur in der Rootdomäne.

Schema-Admins– Sind eine der kritischsten Gruppen überhaupt. Mitglieder dieser Gruppe dürfen Veränderungen am Schema von Active Directory vornehmen. Produkte, die das Schema von Active Directory erweitern, wie zum Beispiel Exchange, können nur installiert werden, wenn der installierende Administrator in dieser Gruppe Mitglied ist.

Das Konto „Administrator“ in der ersten installierten Domäne einer Gesamtstruktur ist das wichtigste und kritischste Konto im gesamten System. Es erlaubt den administrativen Zugriff auf alle wichtigen Systemfunktionen und ist Mitglied aller beschriebenen Administratorengruppen.

Einige der Gruppen sind nur in der ersten innerhalb der Gesamtstruktur eingerichteten Domäne definiert. Andere Gruppen erstellt Windows Server 2012 R2 erst nach der Installation bestimmter Dienste wie DNS und DHCP. 

Teil 2: CLI-Zugang via BASH, SSH und vSphere-API

Wurde die VCSA-Appliance erfolgreich ausgerollt, stehen standardmäßig drei „Schnittstellen“ zum System zur Verfügung.

Eine der wichtigsten „Funktionen“ des vCenters ist das Bereitstellen des vSphere Web-Clients durch den Dienst „vsphere-client“. Der Web Client ist dann standardmäßig unter https://<IP-oder-FQDN-VCSA>/ vsphere-client verfügbar. Frühere Versionen (vor 6.0) erforderten noch das explizite Angeben des Ports 9443, bzw. 443 für SSH. Bei der aktuellen Version gilt das nicht mehr.

Übrigens lässt sich die Sprache des Webinterfaces nicht in dessen Einstellungen auswählen, sondern muss über den Browser-Kontext „angefragt“ werden. So liefert beispielsweise der Aufruf 

https://<IP-oder-FQDN-VCSA>/vsphere-client/?locale=en_US

die amerikanische Lokalisierung bei deutsch eingestelltem Browserkontext.

VAMI

Gleichzeit steht wie in Teil 1 dieses Beitrages erwähnt auf Port 5480 die von früheren Versionen bekannte VAMI-Oberfläche zur Post-Konfiguration zur Verfügung. Hier muss man sich dann allerdings mit dem Linux-root-Account anmelden. Nutzer können hier IP-, DNS- und Routing-Einstellungen nachträglich anpassen, das Zeit-Setup einrichten (z. B. durch Abfrage eines NTP-Servers), die Verfügbarkeit von Appliance-Updates prüfen und diese einspielen, das root-Passwort ändern oder den Zugriff aus das System via SSH und/oder Bash freischalten.

VCSA-VM-Konsole

Letzteres erreicht man aber auch auf andere Art und Weise. So stellt die VCSA-VM auch einen ganz normalen Konsolen-Zugang mit einer an die DCUI eines ESXI-Hosts angepassten ncurses-ähnlichen Menüoberfläche zur Verfügung. Schaltet man sich also mittels „VMRC“ oder der vSphere-Client-Console auf die VCSA-VM, findet man analog zum ESXI-Host mit „F2“ Zugang zum Konfigurationsmodus.

Das Freischalten von SSH und/oder BASH ist dann unter „Troubleshooting Mode Options“ möglich.

Appliance-Shell

Standardmäßig ist die BASH nämlich deaktiviert. Ist SSH aktiviert, die Bash aber nicht, landet man an der sogenannten Appliance-Shell. Das Gleiche passiert, wenn man an der VCSA-Console „Alt+F1“ drückt. Die Appliance-Shell erlaubt aus Sicherheitsgründen nur rudimentäre API-Aufrufe. Welche das sind, finde man durch Eingeben von

help api list

sowie

help pi list

heraus. Auf diese Weise kann man z. B. mit

com.vmware.appliance.version1.services.list

alle verfügbaren Dienste der Appliance mit den zugehörigen Start/Stopp/Restart-Optionen auflisten.
Üblicherweise ist die ApplianceShell aber für API-Aufrufe gedacht. Möchte man von hier aus die Bash erreichen (ohne sie vorher aktiviert zu haben) gibt man Folgendes ein:

shell.set –enabled True

shell

Jetzt befindet man sich in der Bash. Möchte man diese „nachhaltig“ als Default-Shell für den root-User aktivieren, kann man wie unter Linux üblich die Datei „/etc/passwd“ mit „vi/vim“ bearbeiten und nach der Zeile für den root-User suchen. Hier ersetzt man am Ende der Zeile „/bin/appliancesh“ durch „/bin/bash“.

Systemdienste

Da es sich bei der VCSA um ein Suse-Linux-Enterprise-System handelt, kann man selbstverständlich sämtliche Dienste der Appliance SysV-Init-like unter „/et/init.d“ einsehen und „steuern“. Der Web-Client ließe sich hier z. B. mittels

./vsphere-client restart

neu starten. Die meisten VCSA-spezifischen Dienste sind zwar am Präfix „vmware-„ zu erkennen, trotzdem braucht es Erfahrung, Services des unterliegenden Linux-Systems und der Appliance auseinander zu halten.
Daher hat VMware zu diesem Zweck eine eigene Service-Schnittstelle „service-control“ implementiert, mit der sich ausschließlich VCSA-spezifische Dienste komfortabel steuern lassen. Das Eingeben ohne Angabe eines spezifischen Dienstes listet alle verfügbaren Dienste, bzw. Kommandos auf. Hierzu man sich auch nicht im Pfad befinden.

service-control

Zum Verlassen der Bash, genügt das Eingeben von „exit“ und man landet wieder an der ApplianceShell. Noch einmal „exit“ loggt aus der ApplianceShell aus und führt wieder zum Login. Zurück zum grafischen Menü geht es wieder mit F2.

vSphere Management Assistant

Eine Vierte und die von VMware favorisierte Art für den Zugriff auf die vCenter-Shell ist der Einsatz der RemoteCLI. Diese ist für Windows und Linux verfügbar und basiert auf Perl. Die Linux-Variante hat VMware zudem in eine komfortabel als OVA ausrollbare Appliance, den „vSphere Management Assistant“ (vMA) verpack, dessen Handhabung Teil drei dieser Tipp-Reihe beschreibt.

Big Data: Wie man Daten zum Klingen bringt – und warum

Die Älteren unter uns, die noch in der Lage sind, den süßen Klang des Einwahlprozesses eines 14.4er Modems pfeifend zu simulieren, mögen diesem Sujet vermutlich mehr Verständnis entgegenbringen. Unsere Generation hat frühzeitig gelernt, dass Töne immer auch stellvertretend für spezifische Informationen stehen können. Aber kein Generation-Y-Bashing an dieser Stelle: rohe, ungezähmte Technik, außerhalb der sicheren Grenzen selbsterklärender Nutzeroberflächen, war nun auch nicht gerade das Gelbe vom Ei. Es geht hierbei allerdings auch nicht um die schnöde „Sounderkennung“ à la Shazaam, der App, mit der man dem Namen nach unbekannte Ohrwürmer im Radio per Analyse des Klangmusters bestimmen kann, sondern um die klangliche Darstellung sowie die darauffolgende kognitive Dekodierung von – aufbereiteten – Daten wie Diagrammen und Infografiken.

Big Data, Smart Data – und Acoustic Data?

Was auf den ersten, äh, Blick seltsam scheint, hat durchaus Potenzial unsere Mediennutzungsgewohnheiten zu verändern – sofern die akustische Aufbereitung einen zusätzlichen Wert liefert. Dieser kann in erhöhter Usability bzw. dem „Ease of Use“ von Informationsangeboten, verbesserter Didaktik – Erzeugung von „A-Ha-Effekten“ – oder auch in weiterführenden Verarbeitungsprozessen auf akustischer Basis – dort wo es sinnvoller ist, mit Klangsignalen statt mit reinen Binärdaten, zu arbeiten – begründet sein. In der Folge möchten wir hierzu drei Praxisbeispiele vorstellen:

1. Immobilienindex als Arie

Der Case-Shiller Home Price Index gilt in den USA als einer der führenden Immobilien-Indizes. Als die Nachrichtenredaktion von npr („National Private Radio“), ein Zusammenschluss der nicht-kommerziellen US-Hörfunksender, über die neuen Monatszahlen auf dem Immobilienmarkt berichten wollte, sah sie sich wie so oft mit dem „Sinnes-Problem“ der Radioarbeit konfrontiert: Was prima in seiner visuellen Darreichungsform funktioniert – die Darstellung der Entwicklung in einem Diagramm oder einer Grafik – stellt die Berichterstattung auf rein akustischem Wege vor erhebliche Probleme. Kompensieren lässt sich dieser Nachteil gewöhnlich nur durch umfassende Verbalisierung, die einen womöglich simplen Sachverhalt durch wortreiches Beschreiben plötzlich übermäßig komplex erscheinen lässt. Bei npr behalf man sich mit einer ungewöhnlichen Vorgehensweise – die Intonation des Diagramms in der Kunstform des Operngesangs. Die Tonlage bildete dabei den Kurvenverlauf der Indexzahlen ab. Die Höhenflüge in den Jahren 2006/2007 werden damit genauso „erhörbar“ wie die darauffolgende Immobilienkrise und der damit einhergehende Preisverfall. Ein Jahrzehnt Preisentwicklung auf dem US-Eigenheimmarkt – gesungen als Oper:


2. Zieleinlauf der 100m-Olympiasieger im historisch-akustischen Vergleich

Die New York Times hat 2010 anlässlich der Olympischen Spiele sehr ausgiebig mit der akustischen Darstellung von originär visuell dargestellten Sachverhalten experimentiert. Vielleicht das eindrucksvollste Beispiel ist die Gegenüberstellung sämtlicher Zieleinläufe der Goldmedaillengewinner bei den Olympischen Spielen seit 1896. Beginnend mit dem schnellsten – Usain Bolt bei seinem Olympiasieg 2010 – wird jeder Olympiasieger entsprechend seiner Einlaufzeit mit einem Ton versehen. Es gelingt damit auf eindrucksvolle Weise, die auf dem Papier zwar eigentlich immensen Zeitabstände zwischen den Sprintern in Echtzeitrelation zu setzen und dadurch die spröden Daten und Fakten um eine „fühlbare“ Dimension zu erweitern.


3. Algorithmen beim sortieren zuhören

Eine weitere Anwendunsgmöglichkeit ist die Statusanzeige bei Datensortierprozessen bzw. die Unterscheidbarkeit von Algorithmen über akustische Signale. Um in den vollen Genuss dieser multimedialen Errungenschaft zu kommen, sollten Sie dringend ihre Lautsprecherboxen auf extralaut stellen und – ganz wichtig – die Untertitel im Youtube-Video einschalten.



    Der Artikel wurde ursprünglich auf nerdwärts.de veröffentlicht.

Teil 1 – Root-Passwort zurück setzen

VMwares auf Suse Linux basierende vCenter Appliance wird zunehmend populärer, zumal es seit Version 6 weder funktionale Einschränkungen gegenüber einem Windows-vCenter gibt, noch Beschränkungen hinsichtlich der Konfigurations-Maxima. Lediglich die verwendete Datenbank unterscheidet sich. Bei der VCSA handelt es sich bei der eingebetteten Datenbank um eine vPostgres-Datenbank; extern lassen sich diverse Oracale-Systeme anbinden.

Vorteile der VCSA

Die VCSA ist gegenüber einem Windows vCenter vor allem sehr pflegeleicht. Sie ist als OVA sehr schnell ausgerollt, obwohl das Ausrollen und die dabei erfolgende Erst-Konfiguration aus einem ISO-File mit Hilfe einer HTML5-basierten-Setup-Datei angestoßen wird. VMware hat dieses Verfahren implementiert, um den Installations-/Upgrade- und Konfigurationsprozess mit der Windows-Version zu vereinheitlichen.

Zudem hat VMware auf Port 5480 einen kleinen webbasierten Post-Konfigurations-Service implementiert, der u. a. das Upgraden der Appliance sehr komfortabel macht, denn dieser Prozess lässt sich nicht über den Upgrade-Manager automatisieren.

Ferner liegt es in der Eigenschaft der VCSA als virtuelle Maschine begründet, das sich diese sehr einfach in etwaige Backup-Prozesse einbinden lässt. Das gilt für das Windows-vCenter natürlich auch, wenn es auf Basis einer virtuellen (Windows)-Maschine implementiert wurde; dann entfällt aber gegenüber der Linux-Appliance der Vorteil, keine Windows-Lizenz zu benötigen.

Der einzige Grund, der noch für die Windows-Version spricht ist, dass diese unter anderem auch den Installer für den Update Manager mitbringt, dessen Server-Komponente (die Client-Komponente ist das entsprechende vCenter-Plugin im nativen vSphere-Client) noch immer ein Windows-Fundament erfordert. Setzt man also auf die VCSA; braucht man z. B. für den Update Manager immer noch einen Windows-Host samt Lizenz und Datenbank. Betreibt man also vCenter und Update Manager auf der gleichen Maschine (und das ist ja auch der Grund, warum VMware beide zusammen ausliefert), kann man für Beide die gleiche SQLServer Express Datenbank verwenden. 

Linux-Fundament

Während sich die frühen Versionen der VCSA (Vers. 5.0 und 5.5) noch merklich an kleine Unternehmen und Einsteiger richteten, kann man das von Version 6.0 also nicht mehr behaupten. Trotzdem sind es auch hier immer noch eher Einsteiger, die auf die Appliance setzen. Und das ist auch die Zielgruppe, die folgender Tipp adressiert, denn erfahrene vCenter-Admin werden wohl kaum das root-Passwort verlegen.

Ganz abwegig ist es aber nicht, weil der root-Zugang eigentlich nur für die Kommandozeile oder den o. e. webbasierten Post-Konfigurationsservice benötigt wird. Und Beides benötigt man im Alltagsbetrieb nicht, sofern alles gut läuft, denn regulär loggt man sich entweder mit eines administrativen Account der vSphere SSO-Domäne am Web Client ein oder mit einem entsprechend berechtigten Active-Directory-Konto.

Und so setzt man das root-Passwort zurück

Ist tatsächlich einmal das root-Passwort verloren gegangen, hilft ein klassischer Linux-Workaround. Hierzu muss man wissen, dass VMwares vCenter-Appliance aktuell auf Suse Linux Enterprise 1 SP3 basiert.

1. Im ersten Schritt bootet man die Appliance neu. Sind die VMware-Tools installiert – und das sollten sie in Form des Paketes „open-vm-tools“ automatisch sein, kann man den Reboot komfortabel im Web Client über das entsprechende Kontextmenü oder mit Hilfe der zugehörigen Funktion in der jeweiligen Console-Anwendung einleiten, etwa VMRC oder der nativen Console im vSphere Client.

2. Auf jeden Fall muss die Console geöffnet ein, um den Boot-Screen und das Grub-basierte Boot-Menü rechtzeitig erreichen zu können. Hier setzt man den Tastaturfokus „in“ die VM, navigiert man dann zum Eintrag „SUSE Linux Enterprise Server for VMware“ und drückt „e“ für Edit.

3. Hier wechselt man dann zur mit „kernel“ beginnenden Zeile und tipp erneut „e“, um die Zeile bearbeiten zu können. Dann ergänzt man am Ende der Zeile den Eintrag

init=/bin/sh.

Dieser sorgt dafür, dass das System beim nächsten Start-Vorgang in eine Shell bootet. Jetzt kann man den Edit-Modus mit „ENTER“ verlassen.

4. Hat man den Edit-Modus beenden, drück man “b”, um in den so genannten Single-User-Mode zu booten.

5. Da hier keine weitere Passwortabfrage erfolgt, kann man jetzt das Kommando

passwd root

aufrufen, um das Passwort des Users „root“ neu setzen zu können. Hier muss man nur den Anweisungen am Bildschirm folgen, also das neue Passwort bestätigen und ggf. die Passwortrichtlinie beachten.

Danach genügt das Eingeben von „reboot“ gefolgt von Enter, um die Appliance mit neu gesetzten root-Passwort starten zu können.

Digitale Serviceportale in der Fertigungsindustrie

Die Qualität und die Effizienz von Servicedienstleistungen sind zu einem erfolgskritischen Faktor für einen ganzen Industriezweig geworden. Service ist schon lange keine Pflichtübung mehr – sondern integraler Bestandteil einer strategischen und profitablen Unternehmensentwicklung. B2B-Kunden erwarten eine permanente Verfügbarkeit von Informationen, eine direkte Reaktion auf Serviceanfragen und die Option, Transaktionen selbständig auszuführen. Sie folgen damit den Spuren, Erwartungshaltungen und Wünschen aller Konsumenten in B2C- und B2B-Ökosystemen. Der wesentliche Unterschied liegt allein in der Tragweite einer verfehlten Servicequalität. Gelingt es Fertigungsunternehmen nicht, Schlüsselkunden reibungslos, proaktiv und schnell zu versorgen, sind die Konsequenzen auf Kundenseite von immenser negativer Wirkmacht. Konkret: Ausfallzeiten in der Produktion,  verfehlte Auftragsziele, drohende Regressansprüche. Jede Störung in den sensiblen, straff durchgeplanten und komplex orchestrierten Produktionsprozessen ist hochsensibel und teuer.

Im Umkehrschluss schätzen Kunden Fertigungsunternehmen mit intelligenten, digitalen Servicedienstleistungen umso mehr. Ausfallrisiken können jedoch durch eine Kombination aus Predictive Maintenance, Self-Service und digitaler Maschinenverwaltung minimiert oder sogar verhindert werden.

Die unternehmensweite strategische Bedeutung von Servicedienstleistungen als Umsatz- und Margenträger in der produzierenden Industrie ist also unbestritten. Eine konsequente Entwicklung weg vom „klassischen Fertigungsunternehmen“ hin zum „Lösungsanbieter für industrielle Investitionsgüter“ ist eine hervorragende Perspektive, um in volatilen Märkten – mit abnehmenden Möglichkeiten zu Preisdifferenzierung und unter schwankenden konjunkturellen Voraussetzungen für Neukundengeschäft – kurzfristig Cashflow und langfristig Erträge und Wachstum zu sichern. Mit einem intelligenten Angebot aus digitalen Serviceleistungen sind Fertiger in der Lage, sich entscheidend vom Wettbewerb zu differenzieren und wesentliche Gewinnbeiträge zu erwirtschaften.

Ein Serviceportal bietet Fertigungsunternehmen die Möglichkeit, vom Getriebenen zum Treiber ihrer wertschöpfenden Dienstleistungen zu werden und ermöglicht, Service innovativ und kundenorientiert auszubauen, um so die Profitabilität und die Kundenbindung zu erhöhen.

Eine leistungsfähige und tief integrierte Serviceplattform wird zur Drehscheibe von Kernprozessen im Bereich Service und zum Umsatztreiber im Aftersales. Abhängig von der konkreten Bedarfslage der Schlüsselkunden und der Ausrichtung des Service-Geschäftsmodells bietet eine digitale Serviceplattform erhebliches Potential für die effiziente und skalierbare Umsetzung von:

  • Digitalisierung von Maschinenverwaltung
  • Garantieabwicklung als digitaler Service
  • Automatisierte Instandhaltung
  • Retourenverwaltung
  • Übergabedokumentationen
  • Predictive Maintenance
  • Retrofit/Optimierung

Fertigungsunternehmen profitieren konkret durch die Optimierung folgender KPIs:

  • Kundenzufriedenheit und Kundenbindung
  • Prozess- und Kontaktkosten
  • Skalierbarkeit der Servicedienstleistungen
  • Entwicklung von digitalen Mehrwertdiensten
  • Cross-Selling, Upselling und Related Products

Die digitale Maschinenverwaltung dient Fertigungsunternehmen dabei als zentraler Aufsetzpunkt für Service und individuelle, bedarfsgerechte Aftersalesvermarktung. Eine digitale Maschinenverwaltung ermöglicht es dem Kunden, alle Service-Aktivitäten im Kontext seiner Maschine und seiner individuellen Aufgaben und Produktionsprozesse zu sehen und durchzuführen. Fertigungsunternehmen profitieren durch eine fokussierte Perspektive auf den Status des Kunden aus Sicht einer konkreten Installed Base und daraus resultierend durch die Vorteile einer zentrierten, effizienten digitalen Betreuung und einer transparenten Bedarfslage für nachgelagerte Umsätze.

Der Verkauf einer Maschine oder Anlage ist im Zeitalter von vernetzten und hochsensiblen Wirtschaftskreisläufen der Industrie 4.0 also nicht das Ende, sondern der Beginn der eigentlichen wertschöpfenden Kundenbeziehung. Darüber hinaus gilt der Aftersales als Wachstumssegment mit einem immensen Volumen. Valide aktuelle Studien ermitteln, dass fertigende Unternehmen in Deutschland im Mittel zwar nur 20 bis 30 Prozent des Umsatzes, jedoch rund 40 Prozent des Gewinns mit flankierenden Dienstleistungen und Ersatzteilen erwirtschaften. Um diese Kundenbeziehungen wertschöpfend digital zu gestalten und auszubauen, kommt dem Aftersales/Service-Sektor eine bedeutende Rolle zu. Das Thema Servicedigitalisierung ist unternehmenskritisches Business Development für das C-Level-Management. Vom CSO über den CIO bis zum CFO.

 

 

Office 365

 

Mit Office 365 können Sie Sicherheitseinstellungen von iPhones/iPads, Android-Geräten und Windows Phone steuern. Auch Verschlüsselungsfunktionen lassen sich aktivieren. In den Sicherheitseinstellungen von Richtlinien können Sie auch die Option „Verbinden von Geräten mit Jailbreak oder Rootzugriff verhindern“ aktivieren. Dadurch schließen Sie große Sicherheitslücken, die durch solche Geräte entstehen können.

Neben Sicherheitseinstellungen auf den Endgeräten, können Sie mit Office 365 MDM auch die Apps auf den Geräten steuern und absichern, die für den Zugriff auf Office 365-Ressourcen verwendet werden. Beispiele dafür sind One Drive for Business oder Office Mobile. Auch Outlook oder andere Anwendungen lassen sich mit Office 365 MDM steuern. Auf diesem Weg können Administratoren Bedingungen festlegen, mit welchen Apps Anwender auf Office 365 zugreifen dürfen, zum Beispiel um Daten in OneDrive for Business auf einem Endgerät zu nutzen. Alle unterstützten Funktionen, und die jeweils kompatiblen Einstellungen, listet Microsoft in der TechNet auf (https://technet.microsoft.com/de-de/library/ms.o365.cc.devicepolicysupporteddevice.aspx).

Die Einrichtung von MDM in Office 365 findet über Assistenten im Office 365 Admin Center statt. In mehreren Schritten konfigurieren Sie zuerst die Cloudumgebung, und erstellen die Richtlinien. Binden Anwender ihre Endgeräte an Office 365 an, werden die Richtlinien automatisiert übertragen, der Anwender muss sein Gerät dazu aber registrieren und der Verwendung der Richtlinien zustimmen, wenn es sich um sein privates Gerät handelt. Verweigern Anwender die Umsetzung der Richtlinie auf einzelnen Geräten, erhalten diese auch keine Anbindung an Office 365.

vSphere 6 – VMs gruppieren

Damit Sie diese Funktion nutzen können, müssen Sie vCenter im Unternehmen verwenden. Eine vApp ist immer ein Objekt innerhalb eines Clusters auf Basis von vCenter. Einzelne vSphere-Hosts können mit diesem Container nicht anfangen, sie werden durch vCenter entsprechend gesteuert. Einer der Vorteile beim Einsatz von vApp ist, dass Sie alle VMs, die sie in einer vApp zusammenfassen in einen gemeinsamen Container exportieren können. Hier haben Sie auch die Möglichkeit einen Export in eine virtuelle Appliance durchzuführen. Virtuelle Appliances sind VMs, die auf Basis eines offenen Dateiformates zur Verfügung gestellt werden.

Über das Kontextmenü eines Clusters, oder eines Hosts finden Sie den Menüpunkt „Neue vApp“. Hier können Sie entweder manuell eine vApp erstellen, oder Sie verwenden eine Vorlage aus Ihrer Bibliothek. Die Möglichkeit die Sie bei der Zuweisung von Ressourcen an eine vApp haben entsprechen im Grunde genommen den Möglichkeiten eines Ressourcenpools. Sobald Sie eine vApp erstellt haben, wird diese als Container unterhalb des Clusters angezeigt. Damit eine VM in eine vApp integriert werden kann, muss diese Option in den Eigenschaften einer VM erst aktiviert sein. Standardmäßig erstellt vSphere VMs mit aktivierter vApp-Option. Sie finden die Einstellungen von VMs für die Unterstützung einer vApp über den Menüpunkt „vApp-Optionen“. Sie haben auch die Möglichkeit über das Kontextmenü der vApp alle VMs auf einmal ein- oder auszuschalten.

Teil 2: Wenn sich Datastore-Objekten nicht aus dem Inventory entfernen lassen

Einfacher als das Löschen von VMFS-Datastores ist das Hinzufügen oder Entfernen von NFS-Datastores, weil es sich ja hierbei nur um Mount-Prozesse handelt; welche die unterliegenden Dateisysteme (ext4, NTFS, etc.) und Daten nicht tangieren.

Gelingt das Löschen von NFS-Datastores aber trotzdem über die GUI nicht, hilft in der Regel die Kommandozeile weiter. Zu beachten ist hierbei, dass der betreffenden NFS-Datastore von JEDEM Host zu entfernen ist, der mit dem Datastore verbunden war, etwa mit:

cd /vmfs/volumes
esxcli storage nfs remove –v <Name-Datastore>

NFS-Datastores aus dem Inventory entfernen

Nach dem wir im ersten Teil des Beitrages gezeigt haben, was beim Löschen von VMFS-Datastores zu beachten ist, wenden wir uns jetzt dem Problem zu, dass bereits dis-mountete NFS-Datastores trotzdem noch im Inventory rumgeistern.

Im Folgenden Bespiel bestand aufgrund vom Umstrukturierungsmaßnahmen in einem kleinen Unternehmen die Notwendigkeit, die IP-Adresse eines NAS-Gerätes zu ändern, der im Wesentlichen als ISO-Store diente. Nach den Neuanlegen des NFS-Datastores mit korrekter Adresse und gleichem Pfad zum freigegebenen Ordner, tummelten sich beide Datastores im Inventory und der Kontextmenüeintrag „Unmount Datastore“ des ursprünglichen Datastores war ausgegraut.

Auch ein

esxcli storage nfs remove –v <Name-Datastore>

funktionierte nicht.

Verwandte Objekte aufschlussreich

Ein Blick im Web-Client zu „<Datastore-Name>/Related Objects/Virtual Machines“ erübrigte sich zwar, da es sich per Definition um einen ISO-Datastore handelte, wohl aber fördert ein Blick in „<Datastore-Name>/Related Objects/VM Templates in Folders“ zu Tage, dass eine Reihe von Templates noch mit Verweisen auf den betreffenden Datastore verknüpft waren.

Allerdings scheiterte auch ein „Delete from Disk“ für das betreffende Template-Objekt mit der Fehlermeldung „A specific parameter was not correct: Config.spec .files.vmPathName“, was wiederum darauf hindeutet, dass im vCenter-Iventory im „CustomizationSpecManager“ offenbar noch Spec-Files existierten, die vom betreffenden Template-Objekt abhingen.

Hier half es, die betreffenden Templates nicht mit „Delete from Disk“, sondern mit „Delete from Inventory“ zu entfernen. Die nicht mehr gültigen Datastores wurden dann automatisch entfernt.