Hope This Helps

Problem:
Ich habe mich an den ersten Server 2016 Systemen versucht und bin gleich auf einen Bug in der "Aufgabenplanung" gestolpert.
Das Problem ist, dass ich versucht habe mehrere Aufgaben zu bestimmten Zeiten laufen zu lassen (Robocopy etc.)
Ein manuelles Starten des Tasks lief problemlos. Aber die Jobs wurden, beim erreichen der geplanten Zeit, nicht ausgeführt!
Nach langer Suche bin ich tatsächlich auf mehrere englische Foreneinträge gestoßen, die hier das gleiche Problem beschreiben.

Wenn Uhrzeit und Datum der ERSTEN Ausführung in der Vergangenheit liegen, dann läuft der Task nicht, wird aber immer wieder neu eingeplant - nur nicht ausgeführt! Man sieht auch, dass sich das Datum der letzten Ausführung nicht ändert!

Lösung:
Gegenwärtig (03.04.2017) habe ich hierfür keine Lösung gefunden!
Es gibt einen Workaround, dass man das Datum manuell in die Zukunft legt und dann läuft der Task auch - bis zum nächsten Neustart des Server - dann tritt das Problem wieder aus. Also wieder alle Tasks in die Zukunft verlegen und dann läuft das !
Ich werde mich erst Mal mit einem Server 2012 R2 begnügen, da das Problem hier nicht auftritt!

Quelle der Recherche:
serverfault: Task Scheduler in Server 2016 Datacenter Edition Doesn't Run Automatically
serverfault: Windows Server 2016 scheduled task schedule must be in future

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:
Ich habe versucht meine Windows 2012 R2 Standard ROK Lizenz unter VMware 6 zu installieren. Dabei bin ich gleich am Anfang auf eine Meldung gestoßen, dass diese Version nur mit Fujitsu Servern funktioniert:

"This installer is designed to load only in virtual environments supported by Fujitsu and/or the virtual maschine provider."



Da meine ESX-Host Fujitsu-Server sind, habe ich nach einer Möglichkeit gesucht, die BIOS-Informationen in die VM durchzureichen.
Der Eintrag SMBIOS.reflectHost = "TRUE" hat nichts gebracht.

Lösung:
Das Problem ist, dass man bei VMware 6 bzw. System ab Server 2008R2 noch zwei zusätzliche Parameter in der VM eingeben muss. Ich habe folgende Parameter in die VM-Einstellungen konfiguriert und konnte damit meine ROK erfolgreich installieren und aktivieren:

SMBIOS.reflectHost = "TRUE"
SMBIOS.noOEMStrings = "TRUE"
smbios.addHostVendor = "TRUE"

Die Parameter trägt man nicht direkt in die vmx-Dateien ein, sondern kann diese ganz einfach in den Einstellungen der VM eintragen. Dazu folgende Anleitung:

1. VM-Einstellungen bearbeiten
2. Reiter "VM-Optionen" auswählen
3. Erweitert auswählen
4. Button "Konfiguration bearbeiten"
5. Hier die drei zusätzlichen Parameter hinzufügen
6. Alles mit OK bestätigen
7. Maschine starten und ROK-Lizenz installieren

Quelle: VMs mit ROK Key installieren

Jeder Admin wird sich jetzt denken "was soll das denn nun ?" aber trotzdem schreibe ich hier mal etwas zu diesem Thema.
Es dient auch mir als kleiner Spicker

In beiden Beispielen wird die letzte Version eines Ordners im root Ordner mit latest verlinkt.

Unter Linux ist es möglich sogenannte Links zu setzen. Die verhalten sich wie normale Ordner bzw Dateien liegen aber eigentlich an einem anderen Ort im Dateisystem. Somit kann man einfach z.B. das Storage einer Owncloud auf einen NFS Share legen oder, was auch gerne gemacht wird, immer auf die letzte Version einer Datei linken. Der Aufruf dazu ist

ln -s Zielverzeichnis Linkname

löschen kann man den link mit dem Befehl

rm Linkname

Das selbe verhalten kann man auch unter Windows mit mklink nachvollziehen. Das rettet einem manchmal den Tag wenn z.B. der Benutzer die Länge von 256 Zeichen überschritten hat. Dann steigt man tiefer ein und kann die Datei umbenennen oder eben ein Backup durchführen. Früher habe ich dafür immer subst verwendet, das werden jetzt die Windows Admins kennen
Link setzen mit Windows (cmd als Admin)

mklink /D Linkname Zielverzeichnis

Achtung die Parameter sind im Vergleich zu Linux verdreht, passiert mir jedesmal deswegen die Warnung.
Mit dem folgenden Befehl kann man einen Link auf einen Ordner / eine Datei löschen

rmdir Linkname

Kleiner Tipp :
Was man unter Windows damit auch machen kann ist Spiele von Steam, Uplay oder Origin auf eine andere HDD zu schieben.

Informationen zu der Befehlszeile :
technet.microsoft.com - mklink erklärt
wiki.ubuntuusers.de - ln erklärt
technet.microsoft.com - subst erklärt

Problem:
Bei meiner Exchange-Installation wollte ich auf einem Server 2008R2 mittels Powershell alle nötigen Features hinzufügen. Dabei ist mir die Routine immer bei der Installation "NET-HTTP-Activation" auf den Fehler 0x800f081f gelaufen.


Lösung:
Nach einigem Probieren bin ich auf einen Eintrag im Internet gestoßen, wie man das .NetFX3 manuell installieren kann.
Hierzu bitte eine Installations-DVD in das Laufwerk legen (hier E:) und den folgenden Befehl als Administrator starten:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:E:\sources\sxs

Wobei Source: eventuell angepasst werden muss, je nachdem wo das Laufwerk gemountet ist.

Danach ließ sich die die NET-HTTP-Activation problemlos per Powershell installieren.

Problem:
Ich hatte einen Fehler beim Kopieren von Daten mittels Robocopy auf einem Server 2008R2. Hier kam ich folgenden Fehler bei einzelnen Dateien:

„2016/11/21 00:31:28 FEHLER 64 (0x00000040) Folgende Datei wird kopiert D:\blahblahblah.xlsm
Der angegebene Netzwerkname ist nicht mehr verfügbar.“


Lösung:
Nach etwas Suche und Recherche bin ich darauf gestoßen, dass der Parameter /Z in diesem Zusammenhang Probleme machen kann.
/Z : Copy files in restartable mode (survive network glitch)

Leider scheinen manche Shares damit Probleme zu haben, daher habe ich den Parameter komplett entfernt und somit wird per Default /B gewählt.
/B : Copy files in Backup mode

Ich habe jetzt alle Robocopy-Jobs angepasst und getestet…alles gut!