Hope This Helps

Problem : Für Testzwecke habe ich auf einem Server eine 2 postgresql Instanz benötigt.

Lösung : Man kann bei Debian basierenden Systemen eine 2. Instanz mit dem Befehl pg_createcluster erzeugen.

In meinem Fall hab ich das so gemacht :

pg_createcluster -u postgres -g postgres -d /var/lib/postgresql/9.4/main-2 -l /var/log/postgresql/ -s /var/run/postgresql/postgresql-9.4-main-2.log -p 5433 --start-conf auto 9.4 main-2 --start

Zur Erklärung :
-u besitzer des clusters (default ist postgres)
-g gruppe der cluster files (default gruppe von postgres also postgres )
-d dort speichert postgres die dazugehörigen Files zu dem Cluster
-l hier wird das Logfile hingeschrieben
-s hier wird das Unix Socketfile geschrieben
--start-conf auto (default ist auto das bedeutet das das normale init Script die Instanz mitstartet)
9.4 main-2 Version der Postgres DB und der Name (main-2) der Instanz
--start startet den node automatisch nach dem erstellen

Nachdem der Befehl durchgelaufen kann man sich den Stand der jeweiligen Instanz mit dem Befehl pg_lsclusters anzeigen.


Verbinden kann man sich auf die jeweiligen Instanzen mit dem Befehl

sudo -u postgres psql -p [PORT]

Starten oder Beenden eines Cluster Nodes

sudo -u postgres pg_ctlcluster 9.4 main-2 start

sudo -u postgres pg_ctlcluster 9.4 main-2 stop

Verfügbare Aktionen sind : start / stop / restart / reload / status / promote

Problem:
Meine User beschweren sich, dass bei Office 2013/2016 kein Office Picture Manager mehr dabei ist und dieser so komfortabel zu bedienen war.

Lösung:
Man kann den Microsoft Office Picture Manager kostenlos und ohne Lizenz-Probleme nachinstallieren.
Die Idee ist ganz einfach...der Picture Manager ist auch im Microsoft SharePoint Designer 2010 beinhaltet und dieser ist kostenlos im Internet erhältlich.

Folgende Vorgehensweise zur Installation des Picture Managers:
- Microsoft SharePoint Designer 2010 herunterladen (32-Bit-Version): Microsoft SharePoint Designer 2010 (32-Bit)
- Installation angepasst durchführen und alle Punkte deaktivieren außer dem Office Picture Manager


Nach der Installation steht der Picture Manager zur Verfügung. Sollte ein Lizenz-Audit von Microsoft stattfinden, wird nur der SharePoint-Designer ausgelesen und dieser ist kostenlos erhältlich.
Ich weiß, dass die Installationsroutine ca. 400 MB umfasst, aber was tut man nicht für das Wohl seiner User!

Quelle:
IT-Logbuch: Microsoft Picture Manager kostenlos nachinstallieren

Problem:
Ich ziehe gerade unseren Exchange 2007 auf den Exchange 2013 um. Dabei muss ich auch die Transport-Regeln wie z.B. Disclaimer und Weiterleitungen migrieren. Im ersten Augenblick dachte ich, die Übernahme muss manuell erfolgen, was einen nicht unerheblichen Zeitaufwand bedeutet hätte - alleine die Disclaimer mit allen Formatierungen wären viel Arbeit gewesen.

Lösung:
Man kann die Transport-Regeln aus dem alten Exchange 2007 exportieren und in den Exchange 2013 importieren.
Folgende Vorgehensweise hierzu:

Exchange 2007
Öffnen Sie die Powershell auf dem alten Exchange 2007 und führen Sie folgenden Befehl für dne Export aus:

Export-TransportRuleCollection -FileName "C:\ExportedRules.xml"

Danach finden Sie eine Datei ExportedRules.xml unter C:\ vor. Diese kopieren Sie auf den Exchange 2013!

Exchange 2013
Vergewissern Sie sich, dass die Datei ExportedRules.xml auf dem Exchange 2013 vorliegt.
Öffnen Sie die Powershell und führen Sie folgende Befehle für den Import der Transport-Regeln durch:

[Byte[]]$Data = Get-Content -Path "C:\ExportedRules.xml" -Encoding Byte -ReadCount 0 
 Import-TransportRuleCollection -FileData $Data

Danach können Sie in der Exchange-Verwaltungswebsite prüfen, ob unter "Nachrichtenfluss" -> "Regeln" alle Transport-Regeln erfolgreich übernommen wurden. Prüfen Sie bitte auch die Funktionsfähigkeit der Regeln.
Bei mir hat das problemlos funktioniert!

Quelle:
MS Technet: Part 2: Step-by-Step Exchange 2007 to 2013 Migration
Microsoft: You cannot migrate transport rules from Exchange Server 2007 to Exchange Server 2013

Problem : Automatisches Starten der Instanzen bei AWS
Lösung : Man lässt dieses Skript auf einer Maschine/Instanz laufen auf der die aws cli konfiguriert ist.

#!/bin/bash
set -o nounset
set -o pipefail
# Script startet alle definierten Maschinen
AWS_PATH="/root/.local/bin/"
# -----------------------------------------------------------
# Definieren der Maschinen die gestartet werden müssen
# -----------------------------------------------------------
# z.B. declare -a TO_START=("i-xxxxxxxxxxxxxxxxx" "i-xxxxxxxxxxxxxxxxx" "i-xxxxxxxxxxxxxxxxx" "i-xxxxxxxxxxxxxxxxx")
declare -a TO_START=("")
# ------------------------------------------------------------
# nichts mehr ändern
# ------------------------------------------------------------
LOG_PATH="$(dirname $(readlink -f $0))/logs"
LOG_FILE="$(date +%Y%m%d)-awscli.log"
# ------------------------------------------------------------
# Funktionen
# ------------------------------------------------------------
function logger () {
        mkdir -p ${LOG_PATH}
        if [ -z ${2} ]; then
                STATI="INFO"
        else
                STATI="${2}"
        fi
        echo "$(date +%Y-%m-%d) | $(date +%R) | ${STATI} | ${1}" >> ${LOG_PATH}/${LOG_FILE}
}
# ------------------------------------------------------------
logger "Starte -> ${0##*/}" "INFO"
cnt=${#TO_START[@]}
for ((i = 0 ; i < cnt ; i++ )); do
        logger "${TO_START[i]} wird gestartet" "INFO"
        ${AWS_PATH}aws ec2 start-instances --instance-ids ${TO_START[i]} > /dev/null 2>&1
done
logger "Beende -> ${0##*/}" "INFO"
exit 0

Problem : Man hat ein paar Instanzen in der AWS installiert, diese werden aber nur für die Entwicklung bzw. Tests benötigt. Um zusätzliche Kosten zu sparen kann man diese automatisiert außerhalb der benötigten Zeiten herunterfahren.

Lösung : Man lässt dieses Skript auf einer Maschine/Instanz laufen auf der die aws cli konfiguriert ist. Das Beispiel hier läuft selbst eine AWS Instanz. Aus diesem Grund wird mit

OWN_INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)

die eigene ID ermittelt.

#!/bin/bash
# ----------------------------------
set -o nounset
set -o pipefail
# ----------------------------------
#
# Script fährt alle Instanzen herunter bis auf die unter DO_NOT_SHUTDOWN definierten
# die eigene Maschine bleibt natürlich auch online
# PFAD zu awscli
AWS_PATH="/root/.local/bin/"
OWN_INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
# -----------------------------------------------------------
# Definieren der Maschinen die NICHT heruntergefahren werden
# -----------------------------------------------------------
# wenn die eigene Instanz geschützt werden soll diese mit ins Array aufnehmen. Nur so ist gewährleistet das alles abgearbeitet wird
# z.B. declare -a DO_NOT_SHUTDOWN=("${OWN_INSTANCE_ID}" "i-xxxxxxxxxxxxx" "i-xxxxxxxxxxxxx" "i-xxxxxxxxxxxxx")
#
declare -a DO_NOT_SHUTDOWN=("${OWN_INSTANCE_ID}")
# -----------------------------------------------------------
# nichts mehr ändern
# -----------------------------------------------------------
LOG_PATH="$(dirname $(readlink -f $0))/logs"
LOG_FILE="$(date +%Y%m%d)-awscli.log"
# -----------------------------------------------------------
# Funktionen
# -----------------------------------------------------------
function is_inList ()
{
  SERVER=${1}
  max=${#DO_NOT_SHUTDOWN[@]}
  RET=1

  for ((i = 0 ; i < max ; i++ )); do
    if [ "${DO_NOT_SHUTDOWN[i]}" = "${SERVER}" ]; then
      RET=0
      break
    fi
  done

  return $RET
}
function logger () {
        mkdir -p ${LOG_PATH}
        if [ -z ${2} ]; then
                STATI="INFO"
        else
                STATI="${2}"
        fi
        echo "$(date +%Y-%m-%d) | $(date +%R) | ${STATI} | ${1}" >> ${LOG_PATH}/${LOG_FILE}
}
# -----------------------------------------------------------
# Prüfen ob OWN_INSTANCE_ID einen Wert enthält
# -----------------------------------------------------------
logger "Starte -> ${0##*/}" "INFO"
if [ -z ${OWN_INSTANCE_ID} ]; then
        logger "OWN_INSTANCE_ID ist leer Skript wird nicht gestartet" "ERROR"
        logger "Beende AWS Script" "ERROR"
        exit 99
fi

for item in $(${AWS_PATH}aws ec2 describe-instances --query 'Reservations[].Instances[][InstanceId,Tags[?Key==`Name`].Value | [0],LaunchTime,State.Name]' --filters "Name=instance-state-name,Values=running" --output text | awk '{print $1}')
do
        is_inList ${item}
        RET=$?
        if [ $RET -eq 0 ]; then
                logger "${item} wird nicht heruntergefahren definiert in OWN_INSTANCE_ID oder DO_NOT_SHUTDOWN" "INFO"
                continue
        else
                logger "${item} wird heruntergerfahren" "INFO"
                #----  aws cli fährt kiste herunter
                ${AWS_PATH}aws ec2 stop-instances --instance-ids ${item} > /dev/null 2>&1
        fi
done
logger "Beende -> ${0##*/}" "INFO"
exit 0

Problem:
Ich hatte eine RDP-Session, die sich "verrannt" hat und ich konnte auch keinen weiteren Benutzer mehr anmelden.
Stattdessen lese ich folgende Meldung beim Anmeldebildschirm:

"Der angeforderte Vorgang konnte nicht ausgeführt werden, da die Remotedesktopdienste derzeit ausgelastet sind. Versuchen Sie es in einigen Minuten noch einmal. Andere Benutzer können sich normalerweise weiterhin anmelden."

Die Anmeldung mit einem anderen Benutzer ist ebenfalls nicht möglich.
Wie komme ich jetzt an den Server um die Session zurückzusetzen?

Lösung:
Man kann von einem anderen Server/Client aus die Session per Kommandozeile ermitteln und zurücksetzen.
WICHTIG: SIE BENÖTIGEN EINEN BENUTZER, DER ADMINISTRATOR-RECHTE AUF DEM BETROFFENEN SERVER HAT!

1.) Melden Sie sich mit dem administrativen Benutzer an einem anderen Server/Client an

2.) Führen Sie den Befehl "query session /server:" aus, wobei Sie für den Namen des betroffenen Servers eintragen.

3.) In der Ausgabe sollten sie die betroffene Session sehen - merken Sie sich die entsprechende SESSION-ID

5.) Nun setzen Sie die betroffene RDP-Sitzung mit folgendem Befehl zurück: "reset session >SESSION-ID> /server:"
Wobei die Session-ID und der Servername mit den jeweiligen richtigen Werten ersetzt werden müssen.

6.) FERTIG - Die Session wird nun zurückgesetzt - das kann einige Minuten dauern!

Sollte der Fehler häufiger auf Server 2008R2 auftreten, dann gibt es von Microsoft einen Hotfix.
Hier scheint es ein Problem zu geben zwischen dem Prozess csrss.exe und manchen Anwendungen.
Microsoft: KB2661332 - Sie können keine Remotedesktopdienste-Sitzung auf einem Windows Server 2008 R2-basierten Server wiederherstellen.

Quelle:
rodolfovaraujo: How to kill RDP sessions remotely