Die IP-Konfiguration des Integrated Management Modules (IMM) muss nicht zwingend über das BIOS/UEFI geschehen. Sie können diesen Schritt auch direkt über das Betriebssystem erledigen und müssen hierbei nicht einmal den Server neustarten. Lediglich das IMM-Modul wird hier kurz im Kreis gedreht.

Benötigt wird dafür das sogenannte ASU, ein Programm, dass Sie von IBM beziehen können. Laden Sie die für Sie passende Version herunter:

Ältere IBM-Systeme
Neuere Lenovo-Systeme – ab etwa 2015
(Sie müssen jeweils etwas herunterscrollen um den Download aufrufen zu können. Dort sehen Sie dann die kompatiblen Systeme)

Wählen Sie beim Download die HTTPS-Variante, um den unnötigen Downloadmanager zu vermeiden. Laden Sie dann die .exe-Date herunter.

Die .exe-Datei verschieben Sie dann auf dem jeweiligen Host in einen extra Ordner. Der Grund dafür ist, dass Sie beim Klick auf die Datei selbige nur im aktuellen Ordner entpacken. Sie können die ursprüngliche Datei im Anschluss sogar löschen. Der Inhalt des Ordners sollte dann wie folgt aussehen:

Ordnerinhalt

Mit der Kommandozeile sollten Sie sich nun in diesen Ordner begeben. Dann geben Sie bitte folgende Zeilen nacheinander ein:

asu64.exe set imm.hostipaddress1 [IP-Adresse]
asu64.exe set imm.hostipsubnet1 [Subnetzmaske]
asu64.exe set imm.gatewayipaddress1 [Gateway-IP]
asu64.exe set imm.dhcp1 disable
asu64.exe rebootimm

Praktisches Beispiel:

asu64.exe set imm.hostipaddress1 192.168.10.20
asu64.exe set imm.hostipsubnet1 255.255.255.0
asu64.exe set imm.gatewayipaddress1 192.168.10.1
asu64.exe set imm.dhcp1 disable
asu64.exe rebootimm

Der letzte Befehl startet das IMM neu, so dass Sie wenig später die neue IP-Adresse im Browser aufrufen können.

Sofern phpMyAdmin über apt-get installiert wurde, können Sie die Software nur so lange aktualisieren, wie Ihre gewählte Distribution noch neue Versionen unterstützt. Aufgrund aktueller Sicherheitsprobleme wollen wir aber phpMyAdmin in diesem Beispiel auf die wirklich aktuellste Version aktualisieren, welche von der Distribution so nicht mehr unterstützt wird.

Dazu aktualisieren wir die phpMyAdmin-Version zunächst auf die höchste, von der Distribution zugelassene Version:

# Als erstes aktualisieren wir unsere Update-Liste.
sudo apt-get update
# Dann aktualisieren wir phpmyadmin, tatsächlich mit 'install'.
sudo apt-get install phpmyadmin

Normalerweise sollte phpMyAdmin nun unter /usr/share installiert sein. Dort gehen wir nun als nächstes hin.

cd /usr/share

Dort angekommen, entfernen wir das phpMyAdmin-Verzeichnis:

rm -rf phpmyadmin

Mittels wget (muss eventuell zuvor heruntergeladen werden) können wir nun die aktuellste Version über den Hersteller beziehen. Den Link für die .tar.gz-Datei fügen Sie bitte in den nächsten Befehl ein.

# Hier bitte den Link einsetzen und die eckigen Klammern entfernen
wget -P /usr/share/ "[Link]"

# Beispiel 
wget -P /usr/share/ "https://files.phpmyadmin.net/phpMyAdmin/4.8.4/phpMyAdmin-4.8.4-all-languages.tar.gz"

Das heruntergeladene Paket werden wir nun extrahieren, den extrahierten Inhalt in den ursprünglichen Ordner kopieren und letztendlich dann die nicht mehr benötigten Dateien entfernen.

# Entpacken
tar -xvzf phpMyAdmin-4.8.4-all-languages.tar.gz
# Kopieren
cp -r phpMyAdmin-4.8.4-all-languages phpmyadmin
# Rest entfernen
rm -rf phpMyAdmin-4.8.4-all-languages
rm phpMyAdmin-4.8.4-all-languages.tar.gz

Ab jetzt könnte man wieder auf phpMyAdmin zugreifen, wir führen aber noch weitere Anpassungen durch, um Probleme zu vermeiden.

Als erstes erstellen wir ein TMP-Verzeichnis für phpMyAdmin und weißen diesem die richtigen Rechte zu.

# Ins richtige Verzeichnis springen
cd /usr/share/phpmyadmin/
# Ordner anlegen
mkdir tmp
# Rechte anpassen
chown -R www-data:www-data /usr/share/phpmyadmin/tmp

Anschließend erstellen wir noch eine Konfigurationsdatei und passen diese noch ein wenig an. Als Vorlage verwenden wir hier die Sample-Datei.

# Ins richtige Verzeichnis springen
cd /usr/share/phpmyadmin/
# Vorlage kopieren
cp config.sample.inc.php config.inc.php
# Datei editieren
nano config.inc.php

Als erstes fügen wir das Blowfish-Secret ein, um das Kennwort im Cookie von phpMyAdmin zu verschlüsseln. Dazu generieren wir als erstes eine Zeichenfolge, Recherchen haben mich zu folgendem Generator geführt: https://www.motorsportdiesel.com/tools/blowfish-salt/pma/. Die dort ausgegebene Zeile ersetzt die Zeile $cfg[‚blowfish_secret‘] = “; in der Konfigurationsdatei. Beispiel:

$cfg['blowfish_secret'] = '%KE0>eWP`67o]t+Qkw*g^o5CJphcvW';

Prinzipiell sind wir hier fertig und Sie können die Konfigurationsdatei speichern und schließen. Wir haben jedoch noch folgende Anpassungen durchgeführt:

Optional: Warnungen und information_schema-Tabelle ausblenden

Als nächstes bewegen wir unseren Cursor in der Konfigurationsdatei herunter bis zur Stelle /* Server parameters */. Hier hängen wir noch folgende Zeilen an:

/* custom settings */
$cfg['Servers'][$i]['hide_db'] = 'information_schema';
$cfg['PmaNoRelation_DisableWarning'] = true;

Nun können Sie die Konfigurationsdatei abspeichern. Ein Dienstneustart ist nicht erforderlich, die PHP-Seiten werden mit dem nächsten Seitenreload neu eingelesen und übernommen.

Recherchequelle: StackExchange (AskUbuntu)

Man kann mit der Computerverwaltung nicht nur den lokalen Computer verwalten, sondern sich auch remote auf andere Rechner schalten. In unserem Fall war es nun aber so, dass wir von einem Rechner in einer ActiveDirectory-Domain (A) auf einen Rechner drauf wollten, der sich nicht in der Domain befand (B). Der User, mit dem wir uns also auf Rechner B schalten wollten, war selbigem komplett unbekannt. Somit stellte sich die Frage, wie wir uns hier mit einem anderen Benutzer authentifizieren können.

Aber der Reihe nach. Als erstes greifen wir auf die lokale Computerverwaltung zu:

Dort angekommen, können wir uns nun mit dem anderen Computer per IP-Adresse verbinden:

Dies mag sogar manchmal noch gehen, jedoch bekommt man spätestens beim Zugriff auf die Dienste o.ä. einen „Zugriff verweigert“-Fehler zurück.

Um diesen Fehler zu verhindern, gibt es einen ziemlich tollen Trick. Mittels des „net use“-Befehls kann man sich nämlich an einem fremden Rechner authentifizieren, um beispielsweise ein Netzlaufwerk zu mappen. Diese Authentifizierung gilt global, also über das Laufwerkmapping hinaus und somit auch tatsächlich für unsere Computerverwaltung.

Wir öffnen also die Kommandozeile ([Win] + [R] –> cmd) oder PowerShell und geben folgende Zeile ein:

net use \c$ /user:

Damit verbinden wir uns auf die versteckte C$-Freigabe, die auf wirklich jedem PC verfügbar sein sollte. Dabei ersetzen wir die eingefärbten Zeichenfolgen natürlich sinnvoll. Ist der Zielcomputer nicht in einer Domäne, so können Sie „“ weglassen. Statt dem Computernamen können Sie natürlich auch eine IP eintragen.

Sie bekommen dann noch eine Passwortabfrage, die Sie für den User entsprechend ausfüllen sollten. Sofern alles passt, bekommen Sie den Erfolg mit der Meldung „Der Befehl wurde erfolgreich ausgeführt.“ quittiert:

Nun können Sie sich nochmal auf den Remotecomputer schalten und diesen ohne Probleme verwalten können.

Falls Sie Perfomance-Probleme mit Ihrer Dynamics CRM / 365-Instanz haben, können Sie mit den folgenden Schritten etwas mehr ins Detail gehen, um zu sehen, an welcher Stelle es tatsächlich hängt.

Rufen Sie als erstes bitte ein Formular auf, von dem Sie denken, dass es wirklich langsam lädt. In unserem Beispiel verwenden wir das Firmenformular:

Der nächste Schritt ist Browserabhängig:
Internet Explorer: Drücken Sie [Strg] + [Shift] + [Q] zum Aufruf des Performance Centers
Chrome: Drücken Sie [Strg] + [D] und drücken Sie dann auf [Mehr …]. Als URL geben Sie folgende Zeichenfolge ein (ohne Anführungszeichen): „javascript:Mscrm.Performance.PerformanceCenter.get_instance().TogglePerformanceResultsVisibility()“ und als Namen beispielsweise „Performance Center“. Dadurch haben Sie oben nun einen Knopf in der Lesezeichenleiste, den Sie nun drücken um das Performance Center aufzurufen.
Firefox: Drücken Sie [Strg] + [B] um die Lesezeichenleiste aufzurufen. Fügen Sie hier ein neues Lesezeichen mit der URL „javascript:Mscrm.Performance.PerformanceCenter.get_instance().TogglePerformanceResultsVisibility()“ (ohne Anführungszeichen) ein und benennen Sie es treffend. Klicken Sie dieses danach an, während Sie das betroffene Formular im aktiven Tab geöffnet haben.

In allen Fällen sollten Sie nun ein Performance Center sehen. Hier drücken Sie nun nacheinander [Enable] (1) und dann [Close] (2):

Lösen Sie nun einen Reload der Seite aus. Dies kann durch drücken von [F5] oder des „Aktualisieren“-Knopfes erfolgen.

Rufen Sie anschließend wieder das Performance Center auf. Sie sehen nun den Ablauf des Seitenaufbaus (3). Mit dem Knopf [Copy All] (4) können Sie nun die Wartezeiten auch nochmal als Text herauskopieren.

Sollten Sie für unser Hosted Dynamics 365 einen Performance-Auszug machen, so würden wir Sie zum einen um den Text bitten, den Sie über den [Copy All]-Knopf heraus bekommen und zum anderen könnten Sie uns noch einen Screenshot von der Balkendiagramm-Darstellung schicken.

Dies ist ein Beispiel für einen Netplan mit IPv4- und IPv6-Konfiguration. Dabei wurden die IP-Adressen durch allgemein gültige ersetzt.

# Diese Datei beschreibt die verfügbaren Netzadapter in Ihrem System
# Für mehr Informationen netplan(5) aufrufen.
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      # DHCP wird deaktiviert
      dhcp4: no
      dhcp6: no
      # Konfiguration der Adressen, pro Adresse eine Zeile.
      addresses:
        - 192.168.1.123/24
        - 123:4567:ab12:3:192:168:1:123/64
      # Gateways
      gateway4: 192.168.1.1
      gateway6: 123:4567:ab12:3::1
      # Konfiguration der DNS-Server, auch hier mehrere Server respektive Zeilen möglich.
      nameservers:
        addresses:
          - 192.168.1.1
          - 192.168.1.2
          - 123:4567:ab12:3:192:168:1:1
          - 123:4567:ab12:3:192:168:1:2

Angewendet wird der Netplan dann über folgenden Befehl:

sudo netplan apply

Zuerst lassen wir uns die verfügbaren Disks anzeigen, um herauszufinden, auf welcher Disk wir die neue Partition erstellen:

fdisk -l

In unserem Beispiel gehen wir nun von der 2. Disk aus, die über /dev/sdb adressiert wird. Auf dieser Disk erstellen wir nun als erstes ein sogenanntes Physical Volume. Dazu gehen wir zuerst in die LVM-Befehlszeile:

sudo lvm

Anschließend können wir das Physical Volume erstellen:

pvcreate /dev/sdb

Sie können an dieser Stelle auch mehrere Physical Volumes erstellen, die Sie dann im nächsten Schritt zusammenfassen. Wenn Sie mehrere Volumes anlegen wollen, können Sie diese entweder mittels Leerzeichen getrennt an obigen Befehl ranhängen, oder aber den Befehl für jedes Volume entsprechend ausführen.

Das Ergebnis können wir folgendermaßen anzeigen:

pvdisplay /dev/sdb

Nun können wir die zuvor angelegten Physical Volumes zu einer Volume Group zusammenfassen. Dazu geben wir zuerst den Namen an und anschließend die Physical Volumes – wieder durch Leerzeichen getrennt. In unserem Fall haben wir nur eines:

vgcreate sql-vg /dev/sdb

Das Resultat können wir über folgenden Befehl abrufen:

vgdisplay sql-vg

Innerhalb der Volume Group können wir nun endlich die Logical Volumes erstellen – Unsere nachher in Unix sichtbaren Partitionen. Dabei geben wir die Größe der Partition, den Namen und die Volume Group an:

lvcreate -L 199.996G -n sqldata sql-vg

Die Größe wurde übrigens genommen, weil ursprünglich 200G (volle Größe der Volume Group) geplant waren, das aber als „zu groß“ vom System abgelehnt wurde. Deswegen hab ich dann immer 1MB abgezogen und nochmal versucht. Bei 199.996G ging es dann und wurde auch aufgerundet vom System.

Das Resultat können wir wieder mit folgendem Befehl betrachten:

lvdisplay /dev/sql-vg/sqldata

Nun sind wir in der LVM-Befehlszeile fertig und können diese verlassen:

exit

Anschließend formatieren wir unsere neue logische Partition noch mittels folgendem Befehl (ext3):

mke2fs -j /dev/sql-vg/sqldata

Jetzt können wir die neue Partition noch mounten. In unserem Fall wollten wir die Partition direkt unter Root mounten. Dazu erstellen wir ein Verzeichnis am Zielort und mounten die Partition dann:

mkdir /sqldata
mount /dev/sql-vg/sqldata /sqldata

Damit wird die Partition nutzbar. In unserem Fall war es das Datenverzeichnis für unsere ersten Gehversuche mit MSSQL unter Linux.

Ressourcen-Postfächer kann man so konfigurieren, dass Sie Termine automatisch annehmen. Geschieht die Konfiguration über das ECP oder über den simplen

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept

-Befehl, so klappt die automatische Annahme solange, bis ein Terminkonflikt entsteht. In einer Terminserie ist das dann besonders ärgerlich, da alle Serienelemente abgelehnt werden, sobald sich ein Element mit einem vorhanden Termin überschneidet. Dies kann man umgehen, in dem man weitere Parameter anpasst. Grundsätzlich zu klären wäre dabei folgende Frage: Sind Überschneidungen erlaubt?

Wenn Überschneidungen erlaubt sind, kann man die Einstellungen wie folgt überschreiben:

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept -AllowConflicts $true

Damit werden die Termine einfach parallel zu eventuell bereits bestehenden Terminen eingetragen. Das macht dann Sinn, wenn ein Raum beispielsweise doppelt belegbar ist.

Wenn man Überschneidungen vermeiden will und stattdessen wünscht, dass sich überschneidende Termine einfach abgelehnt werden ohne die ganze Serie abzulehnen, so ist folgender Befehl zu verwenden:

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept -AllowConflicts $false -ConflictPercentageAllowed 50 -MaximumConflictInstances 15

Der Parameter –ConflictPercentageAllowed gibt hierbei an, welcher Anteil an Serienelementen auf Grund von Überschneidungen abgelehnt werden darf (in Prozent, aber anzugeben ohne ‚%‘-Zeichen), während -MaximumConflictInstances angibt, wie viele Serienelemente wegen Überschneidungen abgelehnt werden dürfen. Beide Werte kann man dabei natürlich utopisch hochsetzen um zu garantieren, dass jede Serie angenommen wird. Dennoch sind sicher an der ein oder anderen Stelle sinnvoll gewählte Grenzwerte nützlich.

Achtung: Solange -AllowConflicts auf $true steht, haben die für –ConflictPercentageAllowed und -MaximumConflictInstances gesetzten Werte keinen Einfluss, sie werden ignoriert.

Szenario:
IMAP- oder POP3-Verbindungen mittels Email-Clients funktionieren einfach nicht mehr, die Verbindungen werden vom Server sofort wieder geschlossen. Bei der weiteren Recherche stellt sich raus, das man mittels Telnet auf dem Exchange-Server selbst unter Verwendung von 127.0.0.1 die Dienste noch abfragen kann. Führt man jedoch Telnet von einer anderen Maschine remote aus, so wird die Verbindung sofort wieder getrennt. Die jeweiligen Dienste sind jedoch auf dem Server aktiv.

Problem:
Wenn oben beschriebenes teilweise oder gar komplett auf Sie zutrifft, liegt es vermutlich daran, dass die Proxy-Komponente des jeweiligen Dienstes inaktiv ist. Prüfen können Sie das, indem Sie eine PowerShell-Eingabeaufforderung starten, und folgende Zeile eingeben:

Get-ServerComponentState -Identity [Servername]

Folgendes könnten Sie als Ausgabe zurückbekommen:

Server Component State
-------
[...]
[Servername] ImapProxy Inactive
[...]
[Servername] PopProxy Active
[...]

Die Ausgabe ist selbstverständlich nicht eingefärbt, dies dient nur der Veranschaulichung.

Behebung:
Sollte nun eine oder gar mehrere Komponenten als Inactive angezeigt werden, müssen wir selbige wieder aktivieren. Dies erfolgt durch folgenden PowerShell-Befehl:

Set-ServerComponentState -Identity [Servername] -Component [Komponente] -Requester HealthAPI -State Active

In unserem Beispiel würde der Befehl wie folgt aussehen:

Set-ServerComponentState -Identity SRV-EXCHANGE -Component ImapProxy -Requester HealthAPI -State Active

Damit sollten die Verbindungen wieder möglich sein. Eventuell müssen die jeweiligen Dienste noch neugestartet werden.

Ursache:
Auch nach weiterer Recherche konnte nicht herausgefunden werden, was den Server dazu trieb, die Komponente auf inaktiv zu setzen. Zwar sieht man im Eventlog, dass er es tat, aber keinen tieferen Grund. Sollte sich hier noch etwas ergeben, werde ich den Blogeintrag entsprechend erweitern.

Nachtrag:
Scheinbar führt irgendein Softwarefehler beim Exchange Server 2013 regelmäßig zum Absturz solcher Komponenten. Aus diesem Grund wurde ein Script angefertigt, das dieses Problem automatisiert behebt, falls es existent sein sollte. Dieses ist auch TaskScheduler-kompatibel, kann hier also ganz einfach eingesetzt und alle 5 Minuten gestartet werden:

#Ausführung des Remoting-Scripts, der Pfad muss bei anderen Server-Versionen abgeändert werden
. "C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1" | Out-NULL
Connect-ExchangeServer -auto | Out-NULL

$LocalHost = $env:computername

Write-Host "Checking IMAP4: " -NoNewline
$ImapState = (Get-ServerComponentState -Identity $LocalHost -Component ImapProxy).State
if($ImapState -eq "Active")
{
   Write-Host "$ImapState" -ForegroundColor Green
}
else
{
   Write-Host "$ImapState" -ForegroundColor Red
   Write-Host "Enabling Component ImapProxy: " -NoNewline
   Set-ServerComponentState -Identity $LocalHost -Component ImapProxy -Requester HealthAPI -State Active
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting IMAP4 Backend Service: " -NoNewline
   Restart-Service "MSExchangeIMAP4BE"
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting IMAP4 Service: " -NoNewline
   Restart-Service "MSExchangeImap4"
   Write-Host "done." -ForegroundColor Green
}
Write-Host ""

Write-Host "Checking POP3: " -NoNewline
$PopState = (Get-ServerComponentState -Identity $LocalHost -Component PopProxy).State
if($PopState -eq "Active")
{
   Write-Host "$PopState" -ForegroundColor Green
}
else
{
   Write-Host "$PopState" -ForegroundColor Red
   Write-Host "Enabling Component PopProxy: " -NoNewline
   Set-ServerComponentState -Identity $LocalHost -Component PopProxy -Requester HealthAPI -State Active
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting POP3 Backend Service: " -NoNewline
   Restart-Service "MSExchangePOP3BE"
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting POP3 Service: " -NoNewline
   Restart-Service "MSExchangePop3"
   Write-Host "done." -ForegroundColor Green
}
Write-Host ""

Zur besseren Veranschaulichung der Ausgabe besitzt dieses Script einige Zeilen, die im Taskscheduler natürlich unnötig sind. Diese habe ich violett markiert.

Wird über das ECP ein Postfachvollzugriff gewährt, so wird im Hintergrund automatisch der Parameter -AutoMapping auf $true gesetzt. Da dies immer wieder zu Problemen mit den Outlook-Clients führt, möchte man dieses Verhalten eventuell unterbinden.

Nun ist es so, dass man diesen Parameter nicht in bestehenden Regelsätzen verändern kann. Man kann ihn ohne weiteres nicht einmal anzeigen. Daher kann es bei etwas umfangreicheren Berechtigungen durchaus passieren, dass die Änderung mit hohem Aufwand verbunden ist, muss man doch jeden Regelsatz einmal löschen und neu anlegen.

Folgender Code-Schnipsel schafft hier Abhilfe (Erfordert die geladenen Exchange CmdLets):

$Mailbox = "[Name des Postfachs]"
$Permissions = Get-MailboxPermission $Mailbox | Where {$_.User -LIKE "[Optionaler Filter, ansonsten Where-Clause weglassen]"}
foreach ($Permission in $Permissions){
  $PerIdent = $Permission.User
  $PerAccessRights = $Permission.AccessRights
  Remove-MailboxPermission -Identity $Mailbox -User $PerIdent -AccessRights $PerAccessRights -InheritanceType All -Confirm:$false
  Add-MailboxPermission -Identity $Mailbox -User $PerIdent -AccessRights $PerAccessRights -InheritanceType All -AutoMapping $false
}

Dadurch ersetzen Sie die alten Regelsätze durch neue mit deaktiviertem -AutoMapping-Parameter