Gruppenrichtlinie (GPO) für Windows 10: Automatische Zeitumstellung („Automatisch an Sommerzeit anpassen“)

Problem

Windows 10 stellt die Sommerzeit/Winterzeit auf einigen Computern nicht automatisch um. Der Schalter „Automatisch an Sommerzeit anpassen“ für die Zeitumstellung ist im Werkszustand nicht gesetzt. Stichwort DST – DaylightSavingTime.

Es gibt tatsächlich Computerhersteller auf dieser Welt, die ihre Windows 10 OEM-Images so manipuliert haben, das Windows die Sommerzeit/Winterzeit Zeitumstellung nicht mehr automatisch durchführt. Was ein Unfug – wem hilft das? Über den Unsinn der blöden Zeitumstellung an sich brauchen Admins normalerweise nicht streiten, aber sowas macht unseren Job echt unnötig umständlicher.

Lösung

Es gibt glücklicherweise mittlerweile Group Policy Preferences, mit denen man Registry-Settings komfortabel setzen kann.

Die beiden notwendigen Schlüssel lauten:

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"DaylightBias"=dword:ffffffc4
"DynamicDaylightTimeDisabled"=dword:00000000

Diese lassen sich auch mittels Gruppenrichlinie (GPO) verbreiten:

Computerkonfiguration > Einstellungen > Registrierung > Neu > Registrierungselement

vmware vSphere Storage migration „Fehlgeschlagen beim Warten auf Daten. Fehler 195887107. Not found.“

Problem

Einige virtuelle Maschinen lassen sich nicht via Storage Motion oder Storage vMotion auf einen neuen VVOL-Datastore verschieben. Mit andere klappt das fehlerfrei, auch zwischen klassischen Datastores gibt es kein Problem.

Ist die VM eingeschaltet gibt es im Aktivitätsprotokoll die Fehlermeldung

Fehlgeschlagen beim Warten auf Daten. Fehler 195887107. Not found. 

Oder auf English:
A fatal internal error occurred. See the virtual machine’s log for more details.

Ist die VM ausgeschaltet sieht das so aus:

Ein allgemeiner Systemfehler ist aufgetreten: Launch failure

Im /var/log/vmkernel.log stehtm ebenso wenig hilfreich:

OSFS_Lookup:2579: Lookup error: file = rfc4122.b4401030-3010-43a9-8d68-5a76251e5e62, status = Failure
Mirror: scsi0:1: SVMotionLocalDiskCreate: Failed to create destination disk

Spannender ist da schon die Fehlersuche im Protokoll der Maschine, in /vmfs/volumes/<DATASTORE>/<VMNAME>/vmware.log

OBJLIB-VVOLOBJ : VVolObjCheckSize: Requested size (######) is not an MB multiple.

VVolObjDetermineSizeInMB: Requested size (#####) is not a MB multiple.

Mirror: scsi0:1: SVMotionLocalDiskCreate: Failed to create destination disk: The requested size is not a multiple of 1MB.

Lösung

Das Log hat recht: aus irgendeinem Grund hat die virtuelle Maschine eine Festplatte, deren Größe kein ganzzahliges vielfaches von einem Mebibyte ist (1MB).

  • Bearbeiten der virtuellen Maschine
  • Vergrößern der Festplatte auf ein ganzzahliges vielfaches
  • Übernehmen

Fertig, die Maschine kann nun verschoben werden. Man kann der vollständigkeit halber natürlich auch noch das Dateisystem innerhalb der VM vergrößern, aber für den Storage(v)Motion-vorgang ist das nicht notwendig.

Man kann mit PowerCLI auch auf die schnelle herausfinden, welche Maschinen alle betroffen sind:

PC C:\> Get-Datastore | Get-HardDisk | Select Parent, Filename, @{N="Remainder";E={$_.CapacityKB % 1024}} | Where {$_.Remainder -ne 0}

Vielen Dank an den Benutzer in der ehemaligen Nimble-Community, der das herausfand und dokumentierte. Bevor HPE das ganze Forum löschte *seufz*

Gekaufte Blog-Posts und „gesponsorte“ Inhalte

Das es in diesem Internet oft „gekaufte Artikel“ gibt und manche Blogger sogar einen festen Preis für „Sponsored Posts“ haben ist ein offenes Geheimnis. Das solches Sponsoring in letzter Zeit überhand nimmt, vor allem auf Youtube, Twitch und co, wird mittlerweile jedem mit mehr als zwei grauen Zellen aufgefallen sein. Es ist ja schon fast zur Kunst geworden, echte und ehrliche Inhalte zu finden.

Wir machen das nicht.

Wir sind Admins.

Wie so eine Spam-Anfrage aussieht? Ungeschönt, unverändert und original? Mit Antwort natürlich: https://www.ugg.li/in-office-365-die-alternative-e-mail-adresse-oder-handynummer-von-benutzern-anzeigen-auflisten/

vmware Template (Vorlage) auf anderen Datastore verschieben

Problem

Virtuelle Maschinen (Gäste) lassen sich im Gegensatz zu Templates problemlos zwischen Datastores verschieben. Je nach Lizenz mal ein-, mal ausgeschaltet, aber verschieben geht immer. Aus uns nicht bekannten Gründen fehlt die „Migrieren“ Option aber für Vorlagen vollständig. Das gilt sowohl für alle GUIs als auch für das PowerCLI.

Natürlich könnte man diese Vorlagen in Maschinen konvertieren, dann auf dem Storage verschieben und dann wieder zurückkonvertieren, aber geht das nich einfacher?

Lösung

Das geht, kein Problem – im Datastore-Browser.

  • Das Template aus dem Inventar entfernen („Aus Bestandliste entfernen“)
  • Zum Datastore wechseln, wo das Template liegt, zur Inhaltansicht
  • Auf der linken Seite des Datastore-Browsers den Eltern-Ordner des Template-Ordner auswählen
  • Auf der rechten Seite des Datastore-Browsers den Template-Ordner auswählen
  • Oben auf den nun verfügbaren Button „Verschieben nach …“ klicken und das Ziel auswählen
  • Nach dem vollständigen verschieben, zum Ziel-Datastore wechseln, in den nun verschobenen Vorlagen-Ordner
  • Die *.VMTX Datei auswählen und „Zur Bestandliste hinzufügen“

In Office 365 die „Alternative E-Mail Adresse“ oder Handynummer von Benutzern anzeigen/auflisten

Problem

Ein Benutzer möchte sein Office 365 Kennwort zurücksetzen, kann sich aber nicht mehr an seine alternative (zweite) E-Mail Adresse oder seine dafür gespeichterte Handynummer erinnern. Das soll tatsächlich vorkommen …

Lösung

An der Office 365 Powershell kann man der Admin die Alternate-Details „seiner“ Benutzer auflisten …

Get-MsolUser -UserPrincipalName [email protected] | fl aternate*

… und natürlich auch ändern:

Set-MsolUser -UserPrincipalName [email protected] -AlternateEmailAddresses [email protected]
Set-MsolUser -UserPrincipalName [email protected] -AlternateMobilePhones 017355555555