the Sky is the Limit
Duncan Epping und Frank Denneman haben heute das dritte Buch aus der erfolgreichen Deepdive Serie veröffentlicht.
Eines der Standardwerke, das in keinem Bücherregal fehlen darf. Zumindest nicht wenn man sich ernsthaft mit Virtualisierung unter VMware beschäftigt. Wahlweise als Kindle Edition oder klassisch gedruckt.
Es gibt Dogmen in der IT, die werden nicht hinterfragt. Ein solches Dogma ist: „Keine zwei Computer in Windows Domänen dürfen den gleichen Security Identifier SID besitzen“. Aus diesem Grund wurden System Images bei der Verteilung mit Windows-Sysprep, oder Tools wie NewSID behandelt.
Kürzlich beschäftigte ich mich mit Linked-Clones unter VMware View. Dabei stiess ich auf ein alternatives Verfahren zur Vorbereitung von VMs, das mein Interesse weckte. VMware View bietet neben sysprep auch ein Verfahren namens „Quickprep“ an.
| Funktion | Quickprep | Sysprep |
| Removing local accounts | No | Yes |
| Changing Security Identifiers (SID) | No | Yes |
| Removing parent from domain | No | Yes |
| Changing computer name | Yes | Yes |
| Joining the new instance to the domain | Yes | Yes |
| Generating new SID | No | Yes |
| Language, regional settings, date, and time customization | No | Yes |
| Number of reboots | 0 | 1 (seal & mini-setup) |
| Requires configuration file and Sysprep | No | Yes |
Quelle: VMware KB 2003797
Wie kann das gehen? JEDER weiss doch, daß bei der Ableitung ein neuer SID generiert werden muss! Oder etwa nicht?
Bei der Suche nach der Wahrheit fand ich einen Blogartikel von Mark Russinovich, der sich mit dieser Frage beschäftigte. Mark Russinovich ist nicht irgendein Nobody, sondern der Entwickler des oben erwähnten Tools NewSID (damals noch Sysinternals, inzwischen Microsoft). Er räumt auf mit einem Mythos, der seit vielen Jahren in der IT Szene kursiert. In seinem Artikel kommt er zu dem Schluss, daß duplizierte SID innerhalb einer Domäne keinerlei Probleme verursachen – mit einer Ausnahme: Domänencontroller.
As I said earlier, there’s one exception to rule, and that’s DCs themselves. Every Domain has a unique Domain SID that’s the machine SID of the system that became the Domain’s first DC, and all machine SIDs for the Domain’s DCs match the Domain SID. So in some sense, that’s a case where machine SIDs do get referenced by other computers. That means that Domain member computers cannot have the same machine SID as that of the DCs and therefore Domain. However, like member computers, each DC also has a computer account in the Domain, and that’s the identity they have when they authenticate to remote systems.
Ein sehr lesenswerter Artikel. Aber ich bin sicher der Mythos wird uns noch sehr lange begleiten. 😉
Ein Veeam 6.0 Instant Recovery Job hing fest und lies sich mit keinem herkömmlichen Mittel beenden. Weder ein Neustart der Dienste, noch ein Neustart des Servers brachte den Job unter Kontrolle. Letztlich brachte nur ein Eingriff in die Veeam Datenbank, wie sie vom Veeam Support empfohlen wurde, eine Lösung des Problems.
UPDATE [ReportRestoreSessionsAndTaskSessionsView] SET "state" = -1 WHERE "initiator_name" not like 'null'
Interaktionen zwischen der Network Management Card (NMC) einer APC SmartUPS und Powerchute Network Shutdown (PCNS) enthält einige Fallstricke. Es müssen zwei parallel laufende Prozesse (Shutdownskript und USV Shutdown) synchronisiert werden. Wurden hier Fehler gemacht, so schaltet möglicherweise die USV ab, noch bevor alle Server oder VMs beendet werden konnten. Es genügt nicht, den Event „on Battery“ zu konfigurieren und den Pfad zum Shutdown-Script anzugeben. Es ist ebenso wichtig, die geschätzte Dauer des Scripts zu übergeben. Wurde hier keine Zeit definiert (0), dann beginnt die USV sofort mit ihrer Abschalt-Prozedur.
Hier sollte man abschätzen, wie lange der Shutdown Prozess durch das Skript dauern wird und die Zeit mit etwas Toleranz nach oben eintragen. Im Beispiel unten wurden 10 Minuten (=600 Sekunden) geschätzt.
Auch in der NMC ist eine Verzögerung definiert. Ist diese aber zu kurz, so kann das Script nicht rechtzeitig beendet werden. Die USV verwendet entweder die übergebene Zeitspanne aus PCNS oder die eigene Verzögerung. Von beiden Zeiten wird die jeweils längere Dauer gewählt.
Den genauen Ablauf der Ereignisse nach Ausfall der Stromversorgung erklärt der Artikel der APC KB 10563.