Archiv der Kategorie: Allgemein

Tipp: Kostenloses Homebanking Programm/Onlinebanking Programm Jameica/Hibiscus

Nachdem ich mich jahrelang mit überfrachteten und schlecht bedienbaren Onlinebanking-Programmen wie Starmoney, Lexware, WISO Mein Geld herumgeärgert hatte, sprang mir heute die Meldung “Nutzungsperiode abgelaufen” beim Start von WISO Konto Online entgegen. Statt ein Abo für die Software abzuschließen, machte ich mich auf die Suche nach Alternativen. Dabei musste ich feststellen, dass es gerade bei den Onlinebanking-Programmen sehr wenig Auswahl gibt. Eine Suche nach “online banking software” bei Amazon brachte fast nur WISO und Lexware Software. Dann bemühte ich Google. Dabei sah ich, dass es sogar eine kostenlose Homebanking -Software gibt. Jameica/Hibiscus von Olaf Willuhn . Zuerst war ich skeptisch, aber nach dem Download und dem Start der Software lies sich mein Girokonto mit optischen chipTAN Verfahren so schnell und problemlos einrichten, dass sich meine Skepsis in Neugierde wandelte. Der Funktionsumfang des Programms deckt genau das ab was ich von einem Onlinebanking-Programm erwarte:

  • Einfaches Einrichten des Kontos
  • Schneller Abgleich der Umsätze
  • Ein Kategoriensystem um die einzelnen Umsätze Kategorien zuzuordnen
  • Ein flexibler Mechanismus um regelbasiert Umsätze automatisch bestimmten Kategorien zuzuordnen
  • Schnelle und effiziente Möglichkeit Überweisungen zu tätigen
  • Unterstützung des optischen chipTAN Verfahrens
  • Adressverwaltung von Überweisungsempfängern

Ich werde dem Programm auf jeden Fall eine Chance geben. Im Moment sieht es sehr vielversprechend aus. Gerade im Vergleich zu der WISO Onlinebanking-Software, die mich auch nach Jahren nicht überzeugen konnte.

Jedem der auf der Suche nach einem alternativen Onlinebanking-Programm ist, kann ich nur empfehlen sich Jameica/Hibiscus anzuschauen: http://www.willuhn.de/products/hibiscus/

Ansible: Verwenden einer Variable als Name einer Liste mit with_items

Nach dem Update von Ansible 1.7 auf Ansible 2.4 funktionierte eine Ansble Rolle nicht mehr. Bei dieser Rolle wird der Wert einer Variable als Namen einer Liste in einem with_items Konstrukt verwendet.

In Ansible 1.7 funktionierte folgender Syntax noch:

VARS main.yml
---
chooselist: list1

list1:
- { port: '443', src: 'any', proto: 'tcp'}
- { port: '80', src: 'any', proto: 'tcp'}

list2:
- { port: '22', src: 'any', proto: 'tcp'}
- { port: '53', src: 'any', proto: 'tcp'}

TASK:main.yml
---
- name: with_items_test
  debug: msg="{{ item.port }}|{{ item.src }}|{{ item.proto }})"
  with_items: "{{ chooselist }}"

In Ansible 2.4 wird bei obigen Syntax ein Fehler ausgegeben: “The task includes an option with an undefined variable.”

Nach einiger Suche fand ich in folgenden Beitrag “SOLVED: ansible 2.0: with_items: “{{ variable }}_fixstring” resolve issue #14032” die Lösung.

Damit nun Variablen als Namen von Listen mit with_items verwendet werden können, muss man statt

with_items: "{{ chooselist }}"

folgenden Syntax mit dem vars Schlüsselwort verwenden:

with_items: "{{ vars[chooselist] }}"

Der komplette, in Ansible 2.4, funktionierende Task sie dann wie folgt aus aus:

---
- name: with_items_test
  debug: msg="{{ item.port }}|{{ item.src }}|{{ item.proto }})"
  with_items: "{{ vars[chooselist] }}"

Benchmark der neuen Hetzner Cloud VMs mit Apache Bench und Sysbench

Der Hosting-Anbieter Hetzner hat seit Kurzem ein flexibles und relativ preisgünstiges Hosting von virtuellen Servern im Angebot. Das Produkt nennt sich “Hetzner Cloud”. “Cloud” deshalb, weil man nicht direkt fertige virtuelle Maschinen bekommt, sondern eine Umgebung, in der man flexibel seine VM konfigurieren kann. Man kann neben zehn Kombinationen von CPU Cores, RAM, HDD, Speicherart und Speicherart das Datacenter auswählen und die Linux Distribution auswählen. Die Konfiguration der Cloud geschieht in einer ansprechenden Web-Oberfläche. Wenn benötigt, ist die Konfiguration der Cloud auch per API möglich. Was mich positiv überrascht hat, ist die Geschwindigkeit, mit der ein neuer Server ausgerollt wird. Es dauert keine Minute, bis ein neuer Server online per SSH erreichbar ist. Ebenso schnell ist ein Server auch wieder zurückgebaut.

Mit Preisen zwischen 2,96€/Monat und 35,58€/Monat liegt das Angebot in einem attraktiven Rahmen. Um die Leistungsfähigkeit der Hetzner Cloud einschätzen zu können, wurden von sechs verschiedenen Serverkonfigurationen jeweils eine VM erstellt und verschiedene Benchmarks darauf ausgeführt.

Um die Ergebnisse der Benchmarks einordnen zu können, wurden zusätzlich zu den Hetzner Cloud VMs ein Strato vServer und ein Hardwareserver getestet.

Hier die getesteten Server (Stand 02/2018):

Server €/Monat RAM CPU Cores CPU MHz HDD

Inodes

Hetzner Cloud cx11

2,96 €

2GB

1

2100

20 GB 1.224.000,00
Hetzner Cloud cx21

5,83 €

4GB

2

2100

40GB 2.448.000,00
Hetzner Cloud cx31

10,59 €

8GB

2

2100

80GB 4.888.000,00
Hetzner Cloud cx41

18,92 €

16GB

4

2100

160GB 9.768.000,00
Hetzner Cloud cx51

35,58 €

32GB

8

2100

240GB 14.656.000,00
Hetzner Cloud cx41-ceph

18,92 €

16GB

4

2100

160GB 9.768.000,00
Strato vServer Linux V30-49

14,00 €

8GB

4

2000

500GB 6.000.000,00
Hardware Server Linux D400-68

54,00 €

16GB

8

3300

220GB 14.344.192,00

Die Hetzner Server cx11-cx51 unterscheiden sich nur in der unterschiedlichen CPU-, RAM- und HDD-Ausstattung. Die VMs basieren hier auf lokalen SSDs. Diese Konfigurationen sind auf Performance und weniger auf Hochverfügbarkeit ausgelegt. Im Gegensatz dazu bietet Hetzner alle Cloudserver auch noch als Konfiguration basierend auf dem verteilten Speichersystem CEPH an (cx41-ceph). Hier liegen die Dateien der VMs redundant im Netzwerk vor. Positiv fällt auf, dass die Inode Quota der Hetzner Cloud Server angemessen ist. Inodes braucht man z. B. bei einem rsnapshot Backup, bei dem jeder symbolische Link ein Inode verbraucht. Bei kleineren Strato vServern stößt man da schnell an Grenzen.

Auf den ersten Blick ist die Ausstattung der Server mit Festplattenspeicher schlechter als bei den Strato vServern. Dort hat ein Server für 14€/Monat 500GB Festplattenspeicherplatz. Bei Hetzner bekommt man dagegen für z. B. 18€ nur 160GB Speicherplatz. Das könnte für manche Anwendungen ein Problem sein, für die meisten kleineren Webserverprojekte etc. sollte dies aber keine Rolle spielen.

Alle Hetzner Server laufen mit Debian 9, PHP 7, Apache und MariaDB. Die Strato Server mit Debian 8, PHP 5, Apache und MySQL.

Folgende Benchmarks wurden durchgeführt:

IO-Test mit dd

Schreiben eines 1 GB Files mit dd:
(
dd if=/dev/urandom of=/tmp/benchfile bs=1024K count=1024)

Sekunden MB/s
cx11

6,6

162

cx21

7,7

139

cx31

7,7

138

cx41

7,7

139

cx51

7,7

138

cx41-ceph

6,9

154

Strato vSserver

70,1

15

Hardware

79

13

 

Bei diesem Test zeigte sich, dass der Datendurchsatz bei den Hetzner Servern um eine Zehnerpotenz besser ist. Ob hier neben der eigentlichen IO-Leistung noch andere Effekte eine Rolle spielen, kann ich nicht sagen. Die Strato Server, sei es VM oder Hardware, brauchen zehn Mal so lange, um den Test fertigzustellen. Alle Hetzner Server liegen bei diesem Test gleich auf, da hier die Anzahl der CPU Cores keine Auswirkungen auf das Ergebnis hat. Ebenfalls ist zwischen den Hetzner Cloudservern mit lokalem SSD Speicherplatz und verteiltem CEPH Speicher kein Unterschied zu erkennen.

Webserver Benchmark mit AB (Apache HTTP server benchmarking tool)

Mit ApacheBench werden von einem Remote Server Websites auf dem zu testenden Server aufgerufen. Für eine feste Zeitspanne – hier 30 Sekunden – wird ermittelt, wie viele Websites der Server ausliefern kann. Als Website dient bei den Hetzner Servern eine TYPO3 8.6 CMS mit dem Bootstrap Instroduction Package. Bei den Strato Servern dient als Website ein TYPO3 7.6 CMS.

Das Benchmark-Tool wird bei jedem zu testenden Server mit drei unterschiedlichen Anzahlen von gleichzeitigen Request pro Zeitpunkt (Concurrency Level) aufgerufen.

(ab -kc XXX -t 30 http:/WWW.SERVERNAME.TLD/)

Concurrency Level 5

Concurrency Level 50

Concurrency Level 100

Strato vSserver

2451

3851

3696

cx11

3180

4590

4564

cx21

3509

4990

4603

cx31

4105

5531

5336

cx41

4202

10081

9417

Hardware

2702

10155

9609

cx41-ceph

4752

10888

10983

cx51

4453

14818

15379

 


Da ApacheBench einen Stresstest auf einen Webserver ausführt, kommt dieser Benchmark einem realen Workload sehr nahe. Alle Serverkomponenten spielen hier eine Rolle bei der Leistungsfähigkeit.

Was direkt auffällt, ist die sehr gute ApacheBench-Leistung der Hetzner Server, die ab dem Modell cx41 selbst mit einem dedizierten Hardwareserver, der wesentlich mehr kostet, mithalten können. Das cx51-Modell übertrifft sogar die Leistung des Hardwareservers. Ebenfalls fällt auf, dass der CEPH-basierte Cloudserver cx41-ceph sogar eine bessere Leistung hat als sein Pendant mit lokalem SSD Storage.

Hinten, weit abgeschlagen, liegt der Strato vServer, den sogar das kleinste Hetzner Modell cx11 übertrumpft – und das nur für einen Bruchteil der monatlichen Gebühr.

SysBench MySQL

Sysbench MySQL simuliert einen realen MySQL Workload mit Lese- und Schreiboperationen.

(sysbench –test=oltp –oltp-table-size=1000000 –mysql-db=test –mysql-user=test –mysql-password=PASSWORD –max-time=60 –oltp-read-only=off –max-requests=0 –num-threads=[ANZAHL THREADS] run)

1 thread 2 threads 8 threads 32 threads
cx11

730

1476

5516

8591

cx31

708

1521

6320

13358

cx21

712

1508

6246

14122

Strato vSserver

618

1557

5604

14189

cx41-ceph

521

1101

4256

14734

cx41

682

1468

6322

20869

cx51

703

1477

6300

25601

Hardware Server

892

1876

7522

29775

Was bei dem MySQL Sysbench Benchmark auffällt, ist, dass der Hardwareserver hier im Gegensatz zu dem Apache Benchmark leistungsmäßig an der Spitze steht. Die Anzahl der erreichten Transaktionen korreliert hier mit der Anzahl der CPU Cores. Bei zwei gleichzeitigen Threads liegen alle Server noch fast gleichauf. Bei höheren Anzahlen gleichzeitiger Threads sieht man hingegen die Auswirkung der CPU Core Anzahl immer deutlicher.

SysBench CPU Benchmark

Bei dem Sysbench CPU Benchmark wird Zeit gemessen, die benötigt wird, um eine bestimmte Anzahl (hier 10000) von Primzahlen zu verifizieren.

(sysbench cpu sysbench –test=cpu –cpu-max-prime=10000 –num-threads=XX run)

1

2

4

8

16

Hardware Server

8,3

4,2

2,2

1,2

1,2

cx51

10,4

5,2

2,6

1,3

1,3

cx41-ceph

9,1

4,7

2,4

2,4

2,4

cx41

10,3

5,2

2,6

2,6

2,6

Strato vSserver

10,9

5,4

3,7

3,7

3,7

cx21

10,5

5,2

5,2

5,2

5,2

cx31

10,4

5,2

5,2

5,2

5,2

cx11

10,5

10,5

10,8

10,6

11,2

 

Wie zu erwarten, liegt hier der Hardwareserver mit seinen dedizierten CPU Kernen (und der höheren Taktfrequenz) bei dem Sysbench CPU Benchmark wieder an der Spitze. Das Verhältnis der Anzahl der CPU Cores zu der Ausführungszeit ist bei diesem Benchmark fast linear. Eine doppelte CPU Core Anzahl bedeutet eine halbierte Ausführungsdauer.

Fazit

Zusammenfassend betrachtet kann man sagen, dass die neuen Hetzner Cloud Server ein sehr gutes Bild abgeben – sowohl bei der IO-Leistung als auch bei der CPU-Leistung. Bei dem Apache Benchmark übertreffen die zwei größten Cloud Server Konfigurationen selbst den Hardwareserver. Dies hängt aber eventuell auch etwas mit der Leistungssteigerung von PHP 7 im Zusammenspiel mit TYPO3 8 zusammen. Auf den Strato Servern läuft noch Debian 8 mit TYPO3 7 und PHP5, da Strato Debian 9 für seine vServer immer noch nicht (02/2018) unterstützt.

Weiter kann man bei den durchgeführten Benchmarks keine Performance-Unterschiede zwischen den lokalen SSD Speichern und dem verteilten CEPH Speicher erkennen. Bei manchen Tests hatte der CEPH-basierte Server gegenüber seiner gleich konfigurierten Version mit lokalem SSD Speicher die Nase vorn.

Bleibt nur zu hoffen, dass die guten Benchmark-Werte nicht mit einem noch nicht voll ausgelasteten Virtualisierungs- und Speichersystem zu erklären sind. Sollten im Dauerbetrieb die Werte auf dem guten Niveau bleiben, dann wären die cx41 und cx51 Cloud Server eventuell eine Alternative zu einem wesentlich teureren Hardwareserver, bei gleichzeitig mehr Flexibilität und Featuren wie z. B. Snapshots.

Spotty – Spotify Unterstütung für Logitech Sqeezebox Radio

Nachdem Spotify den Support für Logitech Sqeezebox Radio am 20.07.2017 eingestellt hat, war ich kurz davor meinen Spotify Account zu kündigen. Lediglich die umfangreichen Spotify-Playlists hielten mich vor übereilten Aktionen ab. Nach einer Netzrecherche gab es doch noch Hoffnung Spotify auf der Squeezebox hören zu können.

Hier die offizielle Meldung von der Spotify FAQ Seite.

Why can’t I use the Spotify app on my speaker?

LOGITECH
The Spotify integration will be completely removed from the Squeezebox and UE Smart Radiospeakers on July 20th, 2017.

Doch dank eines Entwicklers aus der Squeezebox Community gibt es doch noch eine Möglichkeit Spotify auf der Squeezebox zu hören. Das Plugin heißt Spotty und stammt von Michael Herger.

Um Spotty auf die Squeezebox zu bringen sind folgende Schritte notwendig:

  • Aktualisieren des Squeezebox Server auf die aktuellste Version
  • Installation der Visual C++ Redistributable für Visual Studio 2015 32bit auf dem Squeezebox Server (Prerequirement für die Installation von Spotty)
  • Hinzufügen des Plugin-Repositories für Spotty
    • Aufrufen der Erweiterten Einstellungen in der Squeezebox Systemsteuerung
  • Hinzufügen von http://www.herger.net/slim-plugins/repo.xml als zusätzliche Plugin Repository.
  • Aktivieren des Spotty Plugins in der Pluginliste

Konfiguration des Spotty Plugin (Eingabe der Spotify Credentials)

Danach ist Spotty Auf der Squeezebox unter Eigene Anwendungen zu finden

Spotty - Spotify Plugin für Logitech Squeezebox

Das Plugin funktioniert nach ersten Tests besser als das Originalplugin.

Bleibt nur zu hoffen dass Spotify und Logitech diese letzte Möglichkeit Spotify auf der Squeezebox zu hören nicht auch noch unterbinden. Dann haben mich Spotify und Logitech definitiv das letzte mal gesehen.

Auf seiner Seite hat Michael Herberger einen Link mit dem man ihm eine Donation via Paypal zukommen lassen kann. Ich finde es mehr als fair wenn man das Plugin verwendet dem Autor eine Anerkennung in Form einer Donation zukommen zu lassen.

Test Strato V-Server Version Linux V20

(Stand 30.10.2016)

Die Ausstattung des neuen Linux V20 vServers:

2 vCores (Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz – Effektiver Takt 1998.828 MHz)
4 GB Maxx-RAM 2 GB RAM garantiert
300 GB HDD

Als Vergleich zum Einordnen der Ergebnisse dient ein kleiner Strato-Hardwareserver:

4 CPU Cores (Quad-Core AMD Opteron(tm) Processor 1385 2700.000 MHz)
4 GB RAM
1 TB 7200 rpm HDD (Raid 1)

Nach einigen negativen Erfahrungen mit Strato vServer und ernüchternden Benchmark-Werten von Strato vServer wollte ich mir die neuen Strato V20 VServer anschauen, um herauszufinden, ob sich in Sachen Performance und Stabilität etwas getan hat.

Dazu wurden einige Benchmarks sowohl mit dem neuen vServer V20 als auch mit dem Hardwareserver durchgeführt:

SysBench MySQL

sysbench –test=oltp –oltp-table-size=1000000 –mysql-db=test –mysql-user=test –mysql-password=PASSWORD –max-time=60 –oltp-read-only=off –max-requests=0 –num-threads=[ANZAHL THREADS] run

Anzahl Threads #Transactions vServer V20 Linux #Transactions Hardwareserver
2 2805 (46.73 per sec.) 1271 (21.16 per sec.)
4 4842 (80.65 per sec.) 2596 (43.23 per sec.)
8 8777 (145.83 per sec.) 4984 (82.98 per sec.)
16 13704 (228.29 per sec.) 11297 (188.14 per sec.)
32 18073 (300.73 per sec.) 18978 (315.95 per sec.)
64 19828 (330.07 per sec.) 28705 (478.04 per sec.)
128 20271 (337.04 per sec.) 33187 (532.58 per sec.)

SysBench CPU

sysbench –test=cpu –cpu-max-prime=10000 –num-threads=[Anzahl THREADS] run

Anzahl Threads Dauer(s) vServer V20 Linux Dauer(s) Hardwareserver
1 11.0606s 13.1548s
2 7.6546s 6.5501s
4 7.6804s 3.3243s
8 7.6758s 3.2985s
16 15.1823s 3.3063s

IO Test mit dd

Schreiben eines 1 GB Files mit dd

dd if=/dev/urandom of=/tmp/benchfile bs=1024K count=1024

Anzahl Threads Dauer vServer V20 Linux Dauer Hardwareserver
2 70,5767s (15,2 MB/s) 90,5309s (11,9 MB/s)

Webserver Benchmark mit AB (Apache HTTP server benchmarking tool)

ab -kc [Concurrency Level] -t 30 http://www.WEBSEITE.de/

Concurrency Level #Requests vServer V20 Linux #Requests Hardwareserver
5 1952 2838
10 1968 2778
25 1796 2722

Anscheinend hat Strato nicht nur die Probleme mit den vServern in den Griff bekommen, sondern auch an der Performanceschraube gedreht.

Was auffällt, sind die relativ guten SysBench CPU Werte bei kleiner Threadanzahl im Vergleich zu dem Hardwareserver. Auch scheint jetzt endlich die schon lange beworbene “SSD-Power” bei den Kunden angekommen zu sein. Das zeigen vor allem die im Vergleich zu dem Hardwareserver besseren SysBench MySQL Werte bei niedrigeren Thread-Anzahlen. Auch bei dem IO Test mit dd zeigt der vServer V20 jetzt bessere Werte als der Hardwareserver.

Die Apache Benchmark Werte zeigen endgültig, dass die Strato vServer um Größenordnungen leistungsfähiger geworden sind im Vergleich zu 2015.

Die insgesamt wesentlich höheren Werte bei Apache Bench im Vergleich zum letzten vServer Apache Benchmark kommen von dem nun eingeschalteten PHP opcode Cache, der gerade bei TYPO3 einiges an Performance bringt.

Der einzige Wermutstropfen, der den Einsatzzweck des V20 vServer schmälert, ist die geringe Inode Quota von 800000. Selbst die älteren vServer hatten wenigstens 1000000 Inodes. Bei dem billigsten netcup vServer, der weniger als die Hälfte des kleinsten Strato vServers kostet, bekommt man immerhin 2511552 Inodes, also das 2,5-fache. Wer viele Inodes benötigt, kommt um einen Hardwareserver nicht herum.

Die Ergebnisse noch einmal zusammengefasst:

+ Sehr gute SysBench CPU Leistung

+ Sehr gute SysBench MySQL Werte

+ Gute Apache Bench Werte

+ Großzügiger Festplattenplatz

– Sehr geringe INODE Quota im Vergleich zu Hardwareservern

Webserver Benchmark: Strato Rootserver vs. Strato vServer

Hier ein Benchmark mit dem Linux-Programm ab (Apache HTTP server benchmarking tool). Zielsysteme waren zwei Strato Root Server Linux Hardwareserver und ein Strato Virtual Server Linux. Getestet wurde von einem externen Hardwareserver. Die Dauer der Testläufe betrug jeweils 60 Sekunden. Die gleichzeitigen Requests wurden von 1 bis 250 vaiiert. Aufgerufen wurde die Startseite einer komplexen TYPO3 6.2 Webseite. Die Leistungsunterschiede zwischen den einzelnen Servern zeigen, dass sich “Blech” nur durch noch mehr “Blech” ersetzten lässt. Kleine Strato vServer eignen sich nur für Test- oder Hobbyzwecke. Die beworbene “SSD-Power” bringt für kleine Strato vServer keinen Leistungsschub. Heruntergebremst wird der Strato vServer durch die auf 560 MHz heruntergetakteten vCores.

Hier die Ausstattungen der getesteten Server:

Root Server Linux Medium (bkm-v1411.1.39) 02.2016
Quad-Core AMD Opteron(tm) Processor 1385
4×2.70GHz
bogomips: 5400.07
4 GB Ram
Root Server Linux Small (bkm-v1411.1.29) – 12.2014
Dual-Core AMD Opteron(tm) Processor 1214 HE
2×2.20GHz
bogomips: 2000.00
4 GB Ram
Virtual Server Linux Level 1 Site (Wandel.1406.ERG) – 07.2009
2 vCores
559MHz
2 GB
Webserver Benchmark von Strato Rootserver vs. Strato vServer

Benchmarkergebnisse

DPM Data Protection Manager Fehler ID 30115 VssError: Es ist nicht genügend Speicher vorhanden, um die Schattenkopie-Speicherdatei oder andere Schattenkopiedaten zu erstellen. (0x8004231F)

Bei dem DPM-Fehler:
"ID 30115 VssError: Es ist nicht genügend Speicher vorhanden, um die Schattenkopie-Speicherdatei oder andere Schattenkopiedaten zu erstellen."
handelt es sich um ein Problem auf dem Client und nicht auf dem DPM-Server. Nicht das Replikats- oder Wiederherstellungsvolume auf dem Data Protection Manager ist das Problem, sondern der Speicherplatz für Schattenkopien auf dem Client-Quelllaufwerk.

Der Fehler verhindert, dass erfolgreich DPM-Backups vom Clientlaufwerk erstellt werden können. Auch eine manuelle Konsistenzüberprüfung scheitert augenblicklich.

Auf dem Client zeigt sich folgende Fehlermeldung in der Ereignisanzeige:

Es steht nicht genügend Speicherplatz auf Volume "\\?\Volume{xxxxxxx-cc78-11e4-80b4-xxxxxxxxxxx}" zur Verfügung, um die Schattenkopie von Volume "C:" zu erstellen. Die Erstellung des Schattenkopiespeichers ist fehlgeschlagen.

Um das Problem zu beheben, sind folgende Schritte notwendig:

  1. Öffnen der Datenträgerverwaltung auf dem Client
  2. Auswahl der betreffenden Partition
  3. Kontextmenü – “Eigenschaften” aufrufen
  4. Registerblatt – “Schattenkopien” auswählen
  5. Auswahl des betreffenden Volumes in der Listbox
  6. Aufrufen der Volume-Einstellungen
  7. Setzen der maximalen Größe auf “unbegrenzt”
  8. Bestätigen mit “OK”
  9. Starten einer erneuten Konsistenzprüfung auf dem DPM-Server

DPMErrorID30115

Data Protection Manager DPM Error ID 33424 Fehler beim Sichern einer MS SQL Server Datenbank

Problem:
Beim Anlegen einer Schutzgruppe für eine MS SQL Serversicherung mit dem DPM tritt bei der Replikatserstellung folgender Fehler auf:
“Fehler beim DPM-Auftrag für SQL Server 2012-Datenbank. Der Schutz-Agent verfügt nicht über Systemadministratorprivilegien für die SQL Server-Instanz. (ID 33424)”
Im Gegensatz zu vielen anderen DPM-Fehlermeldungen ist diese sehr selbsterklärend: Der Schutz-Agent verfügt nicht über Systemadministratorprivilegien für die SQL Server-Instanz. Das Dienstkonto, unter dem der DPM Agent auf dem MS SQL Server läuft, braucht Systemadministratorrechte auf dem MS SQL Server-Datenbanksystem. Eine Webrecherche (solve-error-protection-sql-server-dpm) brachte die Bestätigung: “As the error suggests, the problem is that the built-in NT Authority\SYSTEM doesn’t have sysadmin rights.”

Lösung:
Um das Problem zu beseitigen, muss bei einem deutschen System der Account “NT-Authorität\System” als Anmeldung im MS SQL Server angelegt werden und mit den Systemprivilegien “sysadmin” versehen werden. Danach lassen sich die MS SQL-Server-Datenbanken problemlos mit dem DPM sichern.

SharePoint 2013 zeigt fälschlicherweise fehlende Updates auf einem Server an und verhindert dadurch die Ausführung des Konfigurationsassistenten für die SharePoint Farm

Nach einem Patchday kann der Farmkonfigurationsassistent von SharePoint 2013 nicht ausgeführt werden, da angezeigt wird, dass der Patchstand auf den Servern der Farm nicht identisch ist und auf einem Server Updates fehlen würden. Auch die Integritätsanalyse in der SharePoint-Zentraladministration zeigt eine identische Fehlermeldung:

Eine Kontrolle der installierten Updates für SharePoint in der Systemsteuerung zeigt aber, dass die Updates bereits installiert sind. Auch schlägt eine manuelle Installation der Updates mit dem Hinweis fehl, dass diese nicht mehr benötigt werden.

Die Lösung brachte folgender Artikel: SharePoint Cumulative Updates “Error: Some farm products and patches were not detected”

Man soll auf dem betroffenen Server folgenden Powershell-Befehl: Get-SPProduct -Local ausführen. Dieser Befehl aktualisiert anscheinend des Status der installierten SharePoint Updates manuell.

Danach kann man mit dem Powershell-Befehl (Get-SpServer $env:ComputerName).NeedsUpgrade den aktuellen Status überprüfen. Wenn hier false zurückgeliefert wird, ist der Server auf dem aktuellen Stand.

Nach dem Ausführen von Get-SPProduct –Local verschwindet die Fehlermeldung in der SharePoint Integritätsanalyse und auch der Farmkonfigurationsassistent lässt sich wieder ausführen.

Bei Office 365 das Ablaufen der Benutzer-Passwörter deaktivieren (Set up office 365 user passwords to never expire)

Als Standardeinstellung werden bei Office 365 Accounts die Passwörter nach 90 Tagen ungültig bzw. laufen aus und müssen neu gesetzt werden. Wenn man diese Zeit als zu kurz ansieht oder den Zwang, die Passwörter neu zu setzen ganz abschalten will, muss man die Windows PowerShell zu Hilfe nehmen.

Um sich mit der Powershell mit seinem Cloud ActiveDirectory zu verbinden, braucht man zwei Voraussetzungen:

  1. “MS Online Sign In Assistant” Download
  2. Install the Powershell Azure AD Module Download

Sind beide Voraussetzungen installiert, gibt man folgende Befehle in der Powershell Eingabeaufforderung ein:

Import-Module MSOnline

#Hier gibt man seine Administrator-Zugangsdaten ein, mit dem man Office 365 administriert
$msolcred = get-credential

#Verbindungsaufbau zum Active Directory seines Office 365 Accounts
connect-msolservice -credential $msolcred

#Zu bearbeitendes Userobjekt ermitteln
$user=Get-MsolUser -UserPrincipalName “user@domain.tld

# Setzen der PasswordNeverExpires Eigenschaft aus True
$user | Set-MsolUser -PasswordNeverExpires $true

Um die Einstellungen zu kontrollieren, kann man sich alle Eigenschaften des Benutzerobjekts anzeigen lassen:

Get-MsolUser -UserPrincipalName User@Domain.tld | fl

Weitere Infos