Exchange 2013: Übernahme der Transport-Regeln (Disclaimer) vom alten Exchange 2007

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

AWS : automatisierter start der aws instanzen

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

AWS : automatisierter shutdown der aws instanzen

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.
Das Skript fährt alle Instanzen herunter außer diese die in DO_NOT_SHUTDOWN definiert sind.

#!/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


RDP: Wie setzt man eine RDP-Sitzung remote zurück (cmd - Session Reset)

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

DHCP: Einfacher Umzug DHCP-Dienst auf neuen Server mit Anpassung Scope, allen bestehenden Leases und Reservierungen

Problem:
Ich wollte meinen DHCP-Dienst von meinem Server 2008 R2 auf den neuen DC unter 2016 migrieren.
Dabei habe ich nach einer Möglichkeit gesucht nicht alles neu einzutippen, vor allem die Reservierungen wären sehr mühsam gewesen. Wenn man hier für den 2008R2 sucht, wird man nicht fündig - weder über GUI, noch über Powershell. Man muss das ganze vom 2016er-Server angehen. Seit Server 2012 gibt es einen Powershell-Befehl für den Export bzw. Import der DHCP-Konfiguration.

Lösung:
Um die DHCP-Konfiguration vollständig zu exportieren, anzupassen und auf dem neuen Server zu importieren, gehen Sie wie folgt vor.
WICHTIG: FÜHREN SIE ALLE BEFEHLE AUF DEM NEUEN SERVER UNTER 2012R2 ODER 2016 DURCH!!

1.) Installieren Sie auf dem neuen DHCP-Server die DHCP-Rolle, damit die Powershell-Befehle vorhanden sind - überspringen Sie die Konfiguration des Dienstes

2.) Erstellen Sie das Export-Verzeichnis "C:\export" für die Konfiguration an

3.) Führen Sie folgenden Powershell-Befehl für den EXPORT aus (Computernamen anpassen!) :
Export-DhcpServer –ComputerName ALTER-DHCP-SERVER.domain.tld -Leases -File C:\export\dhcpexp.xml -verbose

4.) Jetzt können Sie z.B. die DHCP-Scope in der dhcpexp.xml anpassen. Einfach im Text-Editor öffnen und nach Scope suchen um dann die START- und END-Scope anpassen.

5.) Führen Sie folgenden Powershell-Befehl aus um die Konfiguration in den neuen DCHP-Server zu importieren (Computernamen anpassen):
Import-DhcpServer –ComputerName NEUER-DHCP-SERVER.domain.tld -Leases –File C:\export\dhcpexp.xml -BackupPath C:\dhcp\ -Verbose

6.) FERTIG - Eventuell startet der Install-Wizard beim Öffnen nochmal, diesen einfach abschließen!

Somit ist ein Umzug des DHCP-Servers ohne großen Aufwand und Verlust möglich. Zeitgleich kann ich die SCOPE anpassen, ohne die ganze Konfiguration neu einzugeben.

Kleiner TIPP am Rand: Seit Server 2012 gibt es die Funktion "DHCP-Failover", die man im Modus "Loadbalancer" und "Fail-over" betreiben kann. Sehr schönes Feature, wenn man es braucht!

Quelle:
spiffy.sg: Migrate Existing DHCP Server to Windows Server 2012 easily with PowerShell
“Das Alzheimer-Gesetz der Programmierung: Wenn du einen von dir vor zwei Wochen geschriebenen Code ansiehst, kommt es dir vor als hättest du ihn noch nie gesehen.”
Dan Hurvitz – Software-Entwickler