Hope This Helps

Auslesen der vorhanden E-Mail Aliase eines Users. SamAccountName muss natürlich duch einen echten ersetzt werden

Get-AdUser -Identity 'SamAccountName' -Properties ProxyAddresses | select Name -ExpandProperty ProxyAddresses

Setzen eines zusätzlichen E-Mail Alias. SamAccountName muss natürlich duch einen echten ersetzt werden

Set-ADUser -Identity 'SamAccountName' -add @{ProxyAddresses="smtp:alias1@domain,smtp:alias2@domain" -split ","}

Ich musste die IP-Range eines Standortes komplett ändern, da dieser an unser Netzwerk gekoppelt werden sollte und hier die gleichen IP-Ranges vorlagen. Somit wäre ein Routing zwischen den Standorten nicht möglich gewesen.
Die nachfolgende Liste zeigt meine Gedanken und Vorgehensweisen bzw. Lösungen und ist wahrscheinlich nicht vollständig?!

Vorbereitung für IP-Bereichs-Änderung
- Reverse-Lookup-Zone für neuen Bereich im DNS anlegen
- Replikation der neuen Zone auf DNS-Server prüfen
- DCDIAG erstellt und gespeichert
- DC-Replikation geprüft
- Statische DNS-Einträge dokumentieren
- Eventuelle Skripte oder Dienste auf statische IP-Einträge prüfen (Backups, Netlogon, SMTP etc.)
- Wenn möglich statische IP-Einträge gegen DNS-Einträge tauschen und testen
- Geräte mit festen IPs dokumentieren (z.B. Drucker, Terminals etc.) -> manuelle Anpassung nötig
- DHCP-Optionen dokumentieren
- DHCP-Reservierungen dokumentieren
- Liste mit allen aktiven IP-Adressen und dazugehörigen Geräten erstellen
- Firewall-Regeln dokumentieren
- Routing in der Firewall dokumentieren
- Virenscanner oder anderen Dienste dokumentieren, die IP-Adressen zur Standort-Erkennung verwenden

Umstellung am ersten DC mit FSMO-Rollen
- Neue IP, Subnet und Gateway eintragen
- WINS und DNS sich selbst eintragen
- WINS- und DNS-Dienste starten um Dienstbindung durchzuführen
- ipconfig /flushdns (löscht DNS Cache)
- nbtstat –RR (löschte WINS Cache)
- ipconfig /registerdns (DNS neu registrieren)
- dcdiag /fix (Fixt Probleme im DC und schreibt einige Einträge neu)
- DNS-SRV-Einträge im DNS prüfen ggf. alte löschen (Wichtig sind _GC)
- Restart netlogon

Umstellung der anderen Domain Controller
- Neue IP, Subnet und Gateway eintragen
- WINS und DNS korrekt eintragen (sich selbst als 2. Server eintragen)
- WINS- und DNS-Dienste starten um Dienstbindung durchzuführen
- ipconfig /flushdns (löscht DNS Cache)
- nbtstat –RR (löschte WINS Cache)
- ipconfig /registerdns (DNS neu registrieren)
- dcdiag /fix (Fixt Probleme im DC und schreibt einige Einträge neu)
- DNS-SRV-Einträge im DNS prüfen ggf. alte löschen (Wichtig sind _GC)
- Restart netlogon
- Replikation der DCs testen über "AD Standort und Dienste"
- dcdiag ausführen und speichern
- Ereignisanzeige prüfen

Umstellung DHCP-Server
- Alten DHCP-Scope löschen
- Neuen DHCP-Scope eintragen und Optionen festlegen
- Vorherige DHCP-Reservierungen wiederherstellen
TIPP: Zum Umzug des DHCP-Servers habe ich eine gute Anleitung geschrieben, in der man auch die IP-Range anpassen kann:
DHCP: Einfacher Umzug DHCP-Dienst auf neuen Server mit Anpassung Scope, allen bestehenden Leases und Reservierungen

Umstellung der Memberserver, Clients und sonstiger Geräte
- Neue IP, Subnet und Gateway eintragen
- WINS und DNS korrekt eintragen
- ipconfig /flushdns (falls möglich)
- nbtstat –RR (falls möglich)
- ipconfig /registerdns (Falls möglich/nötig)
- Prüfen der DNS-Einträge auf den DNS-Servern
- eventuellen Restart der Maschinen, Dienste oder Geräten

Sonstige Anpassungen
- Statische DNS-Einträge auf neue IPs ändern
- Dienste und Geräte ggf. anpassen, die nicht auf DNS-Einträge geändert werden konnten
- Firewall-Regeln anpassen
- Routing in Firewall und Netzwerk anpassen
- Virenscanner und andere Dienste anpassen für Standort-Erkennung

Abschlusstests Active Directory
- DCDIAG prüfen
- Eventlogs prüfen
- Alle wichtigen Dienste prüfen (Mail, Fileshares, Datenbanken etc.)
- externe Zugriffe (z.B. VPN) prüfen
- Backup prüfen
- Wichtige Geräte prüfen auf Erreichbarkeit (USV, Switche etc.)

Hier einige Quellen, die mir bei der Lösung geholfen haben:
Microsoft: Change the static IP address of a domain controller
Yusuf: Die IP – Adresse eines Domänencontrollers ändern
ACE FEKAY: So you want to change your IP range?

Problem:
Ich musste die IP eines Domänen-Controllers ändern, da ich einen brandneuen Server 2016er DC aufgesetzt habe, aber keine Lust hatte an allen Druckern, DHCP-Scopes etc. die DNS-IP-Adressen anzupassen.

Lösung:
Eigentlich ist das Ändern relativ einfach, jedoch muss man der AD etwas Zeit geben, bis die Replizierung von AD und DNS durch ist. Folgende Schritte habe ich zur Änderung durchgeführt:

1.) Überprüfen Sie die korrekte Funktion der ActiveDirectory VOR der Umstellung (Replikation, dcdiag)
2.) Ändern Sie die IP-Adresse des betroffenen Domänen-Conmtrollers
3.) Führen Sie ein "ipconfig /registerdns" durch um die DNS-Änderungen zu aktualisieren
4.) Führen Sie ein "ipconfig /flushdns" durch um gecachte DNS-Einträge zu verwerfen
5.) Fühbren Sie ein "dcdiag /fix" durch um SPN-Einträge zu korrigieren
6.) WICHTIG: 5 Minuten nichts machen bis alle DNS/DC die neue IP haben (IT-Kaffee-Hol-Regel)
7.) Im DNS prüfen, ob alle Einträge richtig und nur noch die neuen IPs zu finden sind
8.) Auf allen DCs ein "ipconfig /flushdns" durchführen und den DNS-Cache an den DNS-Servern löschen.
8.) ActiveDirectory prüfen mittels Replikation und dcdiag etc.
9.) WICHTIG: Auf allen laufenden, wichtigen Servern (Exchange, SQL etc.) ein "ipconfig /flushdns" ausführen um die veralteten DNS-Einträge zu löschen - sonst kommt es zu eigenartigen Fehlermeldungen
10.) OPTIONAL: DHCP-Einstellungen anpassen, falls sich DNS-Server auch geändert haben
11.) Fertig! Nächster Kaffee...

Falls man, wie ich, zwei DCs ändern muß (alten DC auf neue IP und neuen DC auf alte IP), sollte man immer zwischen den Änderungen Zeit einplanen, damit die AD alles mitbekommt!

Vorgehenweise um ein sicheres ActiveDirectroy-Schema-Update durchzuführen

Viele haben bestimmt schon ein ActiveDirectory-Schema-Update durchgeführt, ohne sich der Risiken bewusst zu sein, oder diese zu ignorieren. Ich hatte vor kurzem das erste Mal einen Stromausfall bei einem Schema-Update - glücklicherweise in einer Demo-Umgebung. Das Schema war danach zerstört und hatte sich aber beim Neustart der Server bereits repliziert - ActiveDirectory komplett zerstört, nur noch Fehlermeldungen beim Zugriff auf Objekte!
Um das zu verhindern, habe ich mir eine Anleitung zusammengebaut, in der ich wie folgt vorgehe:

1.) Verzeichnis-Replikation auf dem Schemamaster deaktivieren
2.) ADPREP durchführen
3.) Testen des Zugriffs auf die AD (ActiveDirectory-Benutzer und -Computer)
4.) Verzeichnis-Replikation wieder aktivieren
5.) Test der ActiveDirectory

Dazu gehe ich wie folgt vor:

1.) Schemamaster finden
Dazu verwende ich den Befehl "netdom query fsmo" und schau, welcher DC der Schemamaster ist

2.) Aktuelle Schema-Version ermitteln
Hierzu verwende ich auf dem Schemamaster den Befehl DSQUERY.
Hier ein Beispiel für die Domäne DEMO.LOCAL

dsquery * CN=Schema,CN=Configuration,DC=DEMO,DC=LOCAL -Scope Base -attr objectVersion

Kleiner Tipp, falls es sich um ein Exchange-Schema-Update handelt - mit diesem Befehl kann ich die Exchange-Version des Schemas auslesen:

dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=DEMO,dc=INTERN -scope base -attr rangeUpper

3.) Verzeichnis-Replikation auf dem Schemamaster deaktivieren
Hierzu verwendet ich die den Befehl "repadmin" um die eingehende und ausgehende Replikation zu deaktivieren:
(SCHEMAMASTER-NAME muss angepasst werden)

repadmin /options SCHEMAMASTER-NAME +DISABLE_OUTBOUND_REPL
repadmin /options SCHEMAMASTER-NAME +DISABLE_INBOUND_REPL

Danach findet man im Ereignisprotokoll die Ereignisse 1113 und 1115, die darauf hinweisen, dass eingehende und ausgehende Replikation vom Benutzer deaktiviert wurde (Ereignisprotokoll VERZEICHNISDIENST)


4.) Schema-Update durchführen
Jetzt führt man das Schema-Update durch mittels diesen drei Befehlen:

adprep /forestprep
adprep /domainprep
adprep /rodcprep

Im Ereignis-Protokoll werden die Aktualisierungen auch mit protokolliert:


5.) Prüfen der neuen Schema-Version
Nun kann man mittels DSQUERY-Befehl prüfen, ob die neue Schema-Version vorliegt

dsquery * CN=Schema,CN=Configuration,DC=DEMO,DC=LOCAL -Scope Base -attr objectVersion

Als Test dann man sich mal auf einen anderen DC einloggen und den Befehl ebenfalls durchführen.
Hier wird man sehen, dass die Schema-Version noch die alte Version ist, da die Replikation nicht aktiv ist!

6.) Testzugriff auf die AD auf dem Schemamaster
Öffnen Sie einige AD-Konsolen auf dem gerade aktualisieren Schemamaster und klicken Sie sich durch, ob es zu Fehlermeldungen kommt. Wenn alles in Ordnung ist, dann können Sie die Replikation wieder aktivieren.

7.) Replikation wieder aktivieren und das Schema global aktualisieren
Starten Sie auf dem Schemamaster mittels der nachfolgenden Befehle wieder die ein- und ausgehende Replikation:

repadmin /options SCHEMAMASTER-NAME -DISABLE_OUTBOUND_REPL
repadmin /options SCHEMAMASTER-NAME -DISABLE_INBOUND_REPL

Das Aktivieren der Replikation wird ebenfalls wieder im Ereignisprotokoll angezeigt:



8.) Prüfen der neuen Schema-Version
Starten Sie die Replikation der DCs manuell oder warten Sie den Zyklus ab. Danach prüfen Sie auf allen bestehenden DCs, ob das Schema übernommen wurde mittels des vorherigen DSQUERY-Befehl.

9.) FERTIG!

Damit haben Sie eine risikoarme Schema-Erweiterung durchgeführt und minimieren das Risiko, dass die ActiveDirectory beschädigt wird.

Quellen für die Hilfestellung:
Directory Services: Upgrading AD DS Schema to Windows Server 2016
ANTARY: Active Directory Schema Version herausfinden

Problem:
Wenn wir neue Computer in die AD aufnehmen und diese nicht in die richtige OU Verschieben, dann wirken die ganzen GPOs nicht auf den jeweiligen Rechner (Software, Einstellungen, Admins etc.). Ich wollte eine Benachrichtigung beim Anmelden bekommen, wenn der Computer sich noch in der Default-OU befindet. Da die OU "Computers" keine GPOS zulässt, wollte ich neue Computer in einer eigenen OU Erstellen und hier eine Inital-GPO wirken lassen mit Benachrichtigungstext beim Anmelden.


Lösung:
Die Voraussetzungen für die nachstehende Lösung ist eine Domänenlevel mindestens "Windows Server 2003".

Folgende Vorgehensweise um die neue Default-OU für Computer zu erstellen:

1.) Erstellen Sie eine neue OU (z.B. "NewComputers") und schützen Sie diese vor unabsichtlichen Löschen!

2.) Geben Sie auf einem DC folgenden Befehl in einer CMD mit Admin-Rechten ein:
redircmp OU=NewComputers,DC=domain,dc=tld
(z.B. in der Domäne demo.local würde der Befehl wie folgt heißen: redircmp OU=NewComputers,DC=demo,dc=local)

3.) Testen der neuen Einstellung, in dem man einen Computer der Domäne hinzufügt!


Quelle:IT Pro Central: How to define an OU as default location for new Computer objects

Problem : Beim versuch einen Benutzer aus dem Active Directory zu löschen erscheint diese Meldung.


Da ich nicht wusste was das auf sich hat musste ich etwas forschen. Grund war das der User über Active Sync seine Mails auf sein Handy bekommen hat, im laufe der Jahre sind da einige Geräte zusammengekommen.

Lösung : Abfragen der ActiveSync Geräte mit dem Befehl

Get-ActiveSyncDevice | where {$_.userdisplayname –like "*vorname nachname*"}

sind dort welche gelistet müssen diese gelöscht werden. Hier ist der einzeiler der das erledigt.

Get-ActiveSyncDevice | where {$_.userdisplayname –like "*vorname nachname*"} | Remove-ActiveSyncDevice

sollte das nicht funktionieren muss man einen anderen Weg gehen. Wenn z.B. der Benutzer einmal umbenannt wurde kann es nötig sein diesen Weg zu wählen.


Auflisten der ActiveSync Geräte mit

Get-ActiveSyncDevice | where {$_.userdisplayname -like "*vorname nachname*"} | Select-Object Identity

anschließendes löschen der Geräte mit z.B.

Remove-ActiveSyncDevice -Identity "IDENTITY"

Sollte auch dieser Weg nicht funktionieren, kommt z.B. vor wenn das Postfach bereits gelöscht ist, ist das der einfachste Weg.

- Postfach nochmal anlegen
- ActiveSync Geräte entfernen
- Postfach löschen

Quelle :
http://www.mcseboard.de/topic/195314-ad-user-kann-nicht-gel%C3%B6scht-werden/
http://www.ugg.li/exchange-2010-entfernt-mobile-gerate-nicht-das-activesyncdevice-ldapxxxxx-wurde-nicht-gefunden/
https://patrickhoban.wordpress.com/2011/11/22/1344/