Archive for the ‘Kunden’ Category

Festplatten Kontingente bzw. Diskquota unter Windows mittels Kommandozeile setzen

28 September 2017

Da ein Server eines Kunden mitten in der Migration steckte war nirgends das passende Menü zu finden um die Speicherplatzkontingente zu setzen. Vom neuen Server war noch nichts zu sehen, obwohl die Benutzer bereits auf dem neuen Server umgezogen waren.

Die Lösung brachte dann die Verwendung der Kommandozeile in Form von FSUTIL.EXE, denn darüber konnte auf dem alten Server problemlos das Kontingent verändert werden.

C:\>fsutil quota
—- QUOTA Unterstützte Befehle —-

disable         Aktiviert Kontingentnachverfolgung und -durchsetzung.
track           Aktiviert Kontingentnachverfolgung.
enforce         Aktiviert Kontingentdurchsetzung.
violations      Zeigt Kontingentüberschreitungen an.
modify          Legt das Datenträgerkontingent für einen Benutzer fest.
query           Fragt Datenträgerkontingente ab.

So kann mittels “fsutil quota modify” das neue Kontingent gesetzt werden.

Advertisements

“Wie soll diese Website geöffnet werden?”-Dialog wegbekommen

10 März 2017

In bestimmten Situationen, vor allem nach einer Installation oder Deinstallation eines Programms, kann es bei einem neu eingerichteten Windows 10 dazu kommen, dass ein Dialog geöffnet wird mit dem Text:

Wie soll diese Website geöffnet werden?

App verwenden
—–
Standardbrowser verwenden

[  ]  Immer diese App zum Öffnen von <Website> verwenden

OK

Da die Installationen oder Deinstallationen meistens mit Adminrechten durchgeführt werden, kann es zu einer Situation kommen, wenn man die Meldung nicht beachtet und der eigentliche administrative Vorgang bereits abgeschlossen ist, dass die Meldung weiterhin am Bildschirm stehen bleibt und nicht mehr wegzubekommen ist. Das hat mit den fehlenden Rechten des Standardbenutzers nach der Installation zu tun.

Was also tun?

Entweder Rechnerneustart oder im Taskmanager die Datei OpenWith.EXE beenden.

Treiber von Windows 10 im Windows Server 2016 installieren wenn es keine offiziellen Treiber gibt, am Beispiel einer Intel-Netzwerkkarte

7 März 2017

Eigentlich sind sich Windows 10 und Windows Server 2016 recht nahe, je nach Versionsstand von Windows 10. Dennoch gibt es manchmal bei der verwendeten Hardware Einschränkungen in Bezug auf Treiber. In einem aktuellen Fall war in einem Rechner eine Intel I219-V Netzwerkkarte verbaut. Dieser Karte genügt natürlich heutigen Managementansprüchen in Servern nicht unbedingt und deshalb wurde in Server 2016 die Treiberunterstützung für diese Karte unterlassen. Was an dieser Karte aber komisch ist, ist dass es eine Zertifizierung im Windows Server Katalog dafür gibt: https://www.windowsservercatalog.com/item.aspx?idItem=985d89e0-d6d1-b9e0-654c-0209df71a8c7&bCatID=1468.

Was kann man machen um die Karte trotzdem nutzen zu können? Früher ging man her und änderte die zugehörige Treiber-INF-Datei und aktivierte die Windows 10 Treiber für Server 2016. Diese Methode wurde seit Windows Vista Zeiten immer schwieriger. Man benötigt nun passende Zertifikate, damit Änderungen an INF-Dateien autorisiert sind. Man kann aber in Server 2016 noch die bewährte Methode gehen, die Überprüfung der Treibersignatur auszuschalten, dann installiert man einmal die Treiber, ladet und segnet sie ab. Danach aktiviert man wieder die Prüfung der Treibersignaturen. Nun kann man die Geräte mit Windows 10 Treibern unter Windows Server 2016 nutzen.

Für obiges Beispiel beschreibt dieser Blogartikel den Vorgang sehr schön: http://blog.citrix24.com/install-windows-server-2016-core-intel-nuc/.

Hier mache ich aber eine komplette Beschreibung wegen ein paar Besonderheiten und weil oft Blogs im Internet auch verschwinden.

Ermittlung der HardwareID
Fangen wir an die betreffenden Geräte ausfindig zu machen. Normalerweise würden erkannte Netzwerkadapter mittels Get-NetAdapter auftauchen. Aber die Intel I219-V ist nicht dabei. Nun kann man wie im Blogartikel beschrieben mittels

GetWMIObject win32_PNPEntity |select name,deviceid |where {$_.Name match "Ethernet"}

die HardwareID ermitteln, welche

name     : Intel(R) Ethernet Connection I219-V
deviceid : PCI\VEN_8086&DEV_1570&SUBSYS_20638086&REV_21\3&11583659&0&FE

ergibt. Von dieser Info ist die VEN_8086&DEV_1570 von Bedeutung. Im Blogartikel wird noch eine zweite Variante genannt, die bezieht sich auf die WLAN-Karte, welche nicht unter Ethernet zu finden ist, sondern unter Network. Wenn man allerdings unter einem deutschsprachigen Windows diesen Befehl ausführt

GetWMIObject win32_PNPEntity |select name,deviceid |where {$_.Name match "Network"}

dann erscheint nicht die gesuchte Info, sondern

name                                   deviceid
—-                                   ——–
Microsoft Kernel Debug Network Adapter ROOT\KDNIC\0000

weil es Network nicht gibt. Man muss statt dessen nach

GetWMIObject win32_PNPEntity |select name,deviceid |where {$_.Name match "Netzwerkcontroller"}

suchen, um z. B. dieses Ergebnis zu bekommen:

name     : Netzwerkcontroller
deviceid : PCI\VEN_8086&DEV_24F3&SUBSYS_90108086&REV_3A
\4&A711841&0&00E0

Blöd und umständlich so was. Aber wir sind ja auf Server 2016, da gibt es neuere Möglichkeiten Hardwaredinge abzufragen:

Get-PnpDevice -Class Net| select status, friendlyname, instanceid|fl *

status       : OK
FriendlyName : Intel(R) Ethernet Connection I219-V
InstanceId   : PCI\VEN_8086&DEV_1570&SUBSYS_20638086&REV_21\3&11583659&0&FE

status       : Error
FriendlyName : Netzwerkcontroller
InstanceId   : PCI\VEN_8086&DEV_24F3&SUBSYS_90108086&REV_3A
\4&A711841&0&00E0

Prima. Hier sehen wir auch gleich, dass es beim Wirelesscontroller ebenso Probleme gibt, weil dort der Status Error steht. Dies war beim I219-V am Anfang natürlich auch, allerdings sind hier im Beispiel bereits die LAN-Treiber geladen.

Wir müssen uns also nur merken, dass wir anstatt der WMI-Abfrage von Win32_PNPEntity auch direkt Get-PnPDevice –Class Net verwenden können.

Treiber herunterladen und entpacken
Neben der HardwareID benötigen wir auch die passenden Treiber von Windows 10. In diesem Fall waren diese unter https://downloadcenter.intel.com/de/download/ unter dem Stichwort ProWin und ProsetWireless zu finden. Damit man aber mit den Dateien etwas anfangen kann, müssen diese aber entpackt werden. Leider wird es immer mehr zur Unsitte nicht mehr hinzuzuschreiben, wie man Treiber nur entpacken aber nicht installieren kann. Im Zweifel verwendet man 7zip um die Treiber aus den .EXE-Dateien zu extrahieren.

INF-Datei modifizieren
So nun muss man zu den IDs den passenden Treiber finden. Dazu ruft man

Get-ChildItem –Recurse | Select-String –Pattern "VEN_8086&DEV_1570" | group Path | select name

Name
—-
D:\IntelTreiber\PRO1000\Winx64\NDIS62\e1d62x64.inf
D:\IntelTreiber\PRO1000\Winx64\NDIS63\e1d63x64.inf
D:\IntelTreiber\PRO1000\Winx64\NDIS64\e1d64x64.inf
D:\IntelTreiber\PRO1000\Winx64\NDIS65\e1d65x64.inf

auf. Dabei sollte man bereits im Pfad stehen, wo man die Treiber entpackt liegen hat.

Eine Frage ergibt sich, welche Datei man nun bearbeitet? Im konkreten Fall die e1d65x64.inf. Mit den kryptischen Versionen 62, 63, 64 und 65 ist die NDIS-Version gemeint. Windows Server 2016 beherrscht zwar bereits NDIS 6.60 aber ist abwärtskompatibel, deshalb die 65 für Version 6.50. Hier findet man ein paar Infos zu den verschiedenen NDIS-Versionen bei Windowsversionen: https://en.wikipedia.org/wiki/Network_Driver_Interface_Specification.

Man ladet nun die INF-Datei einfach in Notepad, im obigen Beispiel so:

Notepad D:\IntelTreiber\PRO1000\Winx64\NDIS65\e1d65x64.inf

Nun müssen wir uns die Sektionen [Intel.NTamd64.10.0.1] und [Intel.NTamd64.10.0] genauer ansehen. Kurz die 10.0.1 steht für Windows Clientversionen, und 10.0 für Server.

Die Sektionen haben bei INF-Dateien eine besondere Bedeutung. Das lustige ist, dass in der betreffenden INF-Datei nicht nur Windows 10 sondern auch Server 2016 Informationen stehen, ja sogar explizit für die I219-V Netzwerkkarte. Allerdings wurde im für Server entscheidenden Abschnitt die I219-V ausgelassen!

Mehr Infos zu den Herstellerangaben bei INF-Dateien findet man hier, da wird auch der genaue Aufbau der Sektionsnamen beschrieben: https://msdn.microsoft.com/de-de/windows/hardware/drivers/install/inf-manufacturer-section.

Man fügt also unter [Intel.NTamd64.10.0] diesen Eintrag hinzu

%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570
%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570&SUBSYS_00008086
%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570&SUBSYS_00011179

dabei müsste auch

%E1570NC.DeviceDesc%            = E1570,       PCI\VEN_8086&DEV_1570
%E1570NC.DeviceDesc%            = E1570,       PCI\VEN_8086&DEV_1570&SUBSYS_00008086
%E1570NC.DeviceDesc%            = E1570,       PCI\VEN_8086&DEV_1570&SUBSYS_00011179

funktionieren und stellt sogar die sicherere Variante dar.

Treibersignaturprüfung ausschalten
Jetzt kommt der eigentlich wichtigste Punkt. Ohne diesen bekommt man die Sache nicht zum Laufen.

bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS
bcdedit /set TESTSIGNING ON
bcdedit /set NOINTEGRITYCHECKS ON

Für diese Änderung muss allerdings der Rechner neu gestartet werden, also

Restart-Computer

Treiber installieren
Nun kommt der spannende Moment, wenn man die Treiber lädt, ob es klappt.

pnputil.exe -i -a D:\IntelTreiber\PRO1000\Winx64\NDIS65\e1d65x64.inf

Wenn dann so was ausgegeben wird, hat alles geklappt:

Microsoft-PnP-Hilfsprogramm

Verarbeitungsinf.:            e1d65x64.inf
Der Treiber konnte auf einem Gerät dieses Systems installiert werden.
Das Treiberpaket wurde erfolgreich hinzugefügt.
Veröffentlichter Name:            oem2.inf

Versuche gesamt:              1
Anzahl erfolgreicher Importe: 1

Abschlussarbeit
Natürlich muss man nun die Treibersignaturprüfung wieder aktivieren.

bcdedit /set LOADOPTIONS ENABLE_INTEGRITY_CHECKS
bcdedit /set TESTSIGNING OFF
bcdedit /set NOINTEGRITYCHECKS OFF

 

Exchange Server 2010 Postfachweiterleitung und automatischen Abwesenheitstext setzen

5 März 2017

Die Vorgehensweise ist grundsätzlich hier https://support.microsoft.com/de-de/help/2667296/how-to-set-out-of-office-messages-by-using-exchange-2010-powershell beschrieben, allerdings fehlt die Möglichkeit auf eine externe SMTP-Adresse weiterzuleiten. Dieser Punkt wird ausführlich hier beschrieben: http://www.msxfaq.de/exchange/migration/forwardingsmtpaddress.htm.

Wir definieren zuerst eine Variable mit dem Namen des Benutzers:

$identity = "Benutzer"

Zunächst die Abfrage zu den aktuellen Einstellungen eines Benutzers:

Get-MailboxAutoReplyConfiguration -Identity $identity

RunspaceId       : 5531bcbd-6be3-4dad-80c3-dbd1ca1a97d3
AutoReplyState   : Disabled
EndTime          : 06.03.2017 08:00:00
ExternalAudience : All
ExternalMessage  :
InternalMessage  :
StartTime        : 05.03.2017 08:00:00
MailboxOwnerId   : mydomain.local/MyBusiness/Users/SBSUsers/benutzer
Identity         : mydomain.local/MyBusiness/Users/SBSUsers/benutzer
IsValid          : True

und noch die Einstellungen für die Weiterleitung der E-Mails abfragen:

Get-Mailbox –Identity $identity | fl *forw*, name

DeliverToMailboxAndForward : False
ForwardingAddress          :
ForwardingSmtpAddress      :
Name                       : Benutzer

Um die Weiterleitung nun zu aktivieren, verwendet man:

Set-Mailbox –Identity $identity –ForwardingSmtpAddress NeueAdresse@Irgendwo.de –DeliverToMailboxAndForward $true

Um die Weiterleitung wieder zu deaktivieren:

Set-Mailbox –Identity $identity –ForwardingSmtpAddress $null –DeliverToMailboxAndForward $false

Um nun dem ursprünglichen Absender eine Nachricht zukommen zu lassen, verwendet man Set-MailboxAutoReplyConfiguration:

$nachricht = "Guten Tag! Diese Adresse wird zum 30.4.20
17 abgeschaltet. Die E-Mail wird aber an meine neue Adresse weitergeleitet. Bei relevanten E-Mails antworte ich mit mein
er neuen E-Mail-Adresse."
Set-MailboxAutoReplyConfiguration –Identity $identity –AutoReplyState Enabled –InternalMessage $nachricht –ExternalMessage $nachricht

Hier wird für die interne, wie für externe Adressen die Nachricht aus $nachricht zurückgeschickt.

Fragt man die aktuelle Einstellung ab, dann sieht es so aus:

Get-MailboxAutoReplyConfiguration -Identity $identity

RunspaceId       : 5531bcbd-6be3-4dad-80c3-dbd1ca1a97d3
AutoReplyState   : Enabled
EndTime          : 06.03.2017 09:00:00
ExternalAudience : All
ExternalMessage  : <html>
                   <body>
                   Guten Tag! Diese Adresse wird zum 30.4.2017 abgeschaltet. Die E-Mail wird aber an meine neue Adresse
                    weitergeleitet. Bei relevanten E-Mails antworte ich mit meiner neuen E-Mail-Adresse.
                   </body>
                   </html>

InternalMessage  : <html>
                   <body>
                   Guten Tag! Diese Adresse wird zum 30.4.2017 abgeschaltet. Die E-Mail wird aber an meine neue Adresse
                    weitergeleitet. Bei relevanten E-Mails antworte ich mit meiner neuen E-Mail-Adresse.
                   </body>
                   </html>

StartTime        : 05.03.2017 09:00:00
MailboxOwnerId   : mydomain.local/MyBusiness/Users/SBSUsers/Benutzer
Identity         : mydomain.local/MyBusiness/Users/SBSUsers/Benutzer
IsValid          : True

Hier sieht man auch, dass man für Internal- und Externalmessage auch etwas HTML setzen könnte, wenn man sich beim Text künstlerisch betätigen wollte.

Warum schaltet sich dieser verdammte DHCP-Dienst am Windows Server ständig ab? Was hat das mit IPv6 zu tun?

5 Dezember 2016

Irgendwie stand ich gerade auf dem Schlauch und hab mich mit einem Problem länger als nötig beschäftigt um am Ende festzustellen, die Lösung ist logisch und ganz einfach. Es ging los, dass bei einem Kunden der Speedport gegen eine Fritzbox ausgetauscht werden sollte.

Zu Beginn war alles ganz einfach, Internetverbindung war schnell da. Aber dann gab es Probleme im Netz mit den Client-Rechnern nach einem Neustart. Dazu muss man wissen, dass bei der Fritzbox der IPv4-DHCP ausgeschaltet wurde. Egal wie oft man nun am Windows Server den DHCP-Server neu gestartet hat, er funktionierte immer kurz und war dann wieder ausgeschaltet. Sowas kennt man wenn ein zweiter DHCP-Server im Netz ist. Also nochmal auf der Fritzbox versichert, dass der Ipv4-DHCP ausgeschaltet war. Am Ende war nur noch der Server mit dem Client mit der Fritzbox verbunden. Klappte aber immer noch nicht!

Wo schaut man nach, wenn man solche Probleme hat? Richtig, in der Ereignisanzeige. Also kurz nach den DHCP-Server Logs geschaut:

Get-WinEvent -ListLog *dhcp*|select logname

LogName
——-
Microsoft-Windows-Dhcp-Client/Admin
Microsoft-Windows-Dhcp-Client/Operational
Microsoft-Windows-Dhcp-Server/FilterNotifications
Microsoft-Windows-Dhcp-Server/Operational
Microsoft-Windows-DhcpNap/Admin
Microsoft-Windows-DhcpNap/Operational
Microsoft-Windows-Dhcpv6-Client/Admin
Microsoft-Windows-Dhcpv6-Client/Operational

Ah alles klar:

Get-WinEvent -LogName Microsoft-Windows-Dhcp-Server/Operational -MaxEvents 10

TimeCreated                   ProviderName                                             Id Message
———–                   ————                                             — ——-
17.12.2015 12:52:43           Microsoft-Windows-DHCP-Server                           106 Die Rese
17.12.2015 12:52:43           Microsoft-Windows-DHCP-Server                           107 Die Rese
17.12.2015 12:49:25           Microsoft-Windows-DHCP-Server                           106 Die Rese
17.12.2015 12:48:23           Microsoft-Windows-DHCP-Server                           107 Die Rese
25.11.2015 09:12:51           Microsoft-Windows-DHCP-Server                           106 Die Rese
25.11.2015 09:12:24           Microsoft-Windows-DHCP-Server                           107 Die Rese
21.05.2014 14:25:11           Microsoft-Windows-DHCP-Server                           106 Die Rese

Wie 2015? Ich hab aktuell Problem und nicht 2015! Hä? Was geht hier. Auf jeden Fall ist es wie immer man sucht überall aber nicht an der richtigen Stelle!!!!

Irgendwann dachte ich, dass kann nicht sein und klar es war so. Denn man sollte ja auch wegen DHCP-Server Meldungen nicht bei Microsoft-Windows-DHCP-Server schauen sondern unter SYSTEM!!!! Ich könnte so kotzen…

Also mittels

Get-WinEvent -LogName system -MaxEvents 20

TimeCreated                   ProviderName                                             Id Message
———–                   ————                                             — ——-
05.12.2016 14:52:32           Service Control Manager                                7040 Der Starttyp des Diensts "…
05.12.2016 14:50:02           Microsoft-Windows-GroupPolicy                          1500 Die Gruppenrichtlinieneins…
05.12.2016 14:50:01           Microsoft-Windows-GroupPolicy                          1500 Die Gruppenrichtlinieneins…
05.12.2016 14:49:56           Service Control Manager                                7036 Dienst "Windows Modules In…
05.12.2016 14:49:25           Microsoft-Windows-DHCP-Server                          1043 Es wurde festgestellt, das…
05.12.2016 14:49:05           Service Control Manager                                7036 Dienst "DHCP-Server" befin…
05.12.2016 14:49:01           Microsoft-Windows-DHCP-Server                          1056 Der DHCP-Dienst wird auf e…
05.12.2016 14:45:31           Service Control Manager                                7036 Dienst "DHCP-Server" befin…
05.12.2016 14:45:31           Microsoft-Windows-DHCP-Server                          1054 Der DHCP/BINL-Dienst auf d…
05.12.2016 14:45:31           Microsoft-Windows-DHCP-Server                          1053 Der DHCP/BINL-Dienst hat e…
05.12.2016 14:45:19           Service Control Manager                                7036 Dienst "DHCP-Server" befin…
05.12.2016 14:45:15           Microsoft-Windows-DHCP-Server                          1056 Der DHCP-Dienst wird auf e…
05.12.2016 14:45:03           Microsoft-Windows-GroupPolicy                          1500 Die Gruppenrichtlinieneins…

geschaut und hier tauchen dann auch die üblichen Verdächtigen DHCP/BINL-Meldungen auf! Wenn man nun genauer nachschaut, wird es auch offensichtlich:

Get-WinEvent -LogName system -MaxEvents 20| where {$_.id -eq 1053}| ft message -Wrap

Message
——-
Der DHCP/BINL-Dienst hat einen anderen Server mit der IP-Adresse fe80::3a10:d5ff:fe89:bb02 in diesem Netzwerk ermittelt
, der zu der folgenden Domäne gehört: .

Also wo liegt nun das Problem? Warum hab ich oben immer geschrieben, dass ich den IPv4DHCP ausgeschaltet habe? Na klar, weil die Fritzbox auch noch einen IPv6DHCP hat und dieser munter weiter aktiv war. Und da im Netz nunmal unabhängig von IPv4 und IPv6 nur ein DHCP aktiv sein war, hat sich der Windows DHCP-Server immer schneller verabschiedet!

Also Lösung: Entweder IPv6 ganz abschalten oder den IPv6DHCP abschalten! Besser ist natürlich die zweite Variante.

Mal abgesehen davon, dass ich hätte schneller drauf kommen können. ist mir erst durch diese Geschichte wieder aufgefallen, wie inkonsistent die DHCP-Dienst-Sache unter Windowsservern ist. Einfach nur traurig…

Probleme mit leeren Bildschirm bei Sichern und Wiederherstellen unter Windows 7 und allgemeines Sicherungsdebugging

30 Mai 2016

Datensicherungen sind wichtig, gerade in Zeiten von Cryptolocker-Malware. Was macht man aber, wenn man mit einer leeren Seite und ohne Fehlermeldung begrüßt wird, wenn man den Sicherungsstatus überprüfen möchte?

In einem Fall unter Windows 7 zeigte der Aufruf der “Sichern und Wiederherstellen”-Seite über die Systemsteuerung einfach nur ein leeres Bild. Schlecht so was. Auch der direkte Aufruf von sdclt.exe brachte die gleiche Darstellung. Hier ist das Problem nochmal mit Bildern beschrieben: http://www.borncity.com/blog/2014/09/29/windows-sichern-und-wiederherstellen-bleibt-leer/.

Gut wenn die Oberfläche nichts anzeigt, dann schaut man halt tiefer und ein Aufruf von wbadmin get versions brachte erschreckendes zu Tage, dass die letzte Sicherung schon ein paar Wochen her ist!

Dann der nächste Blick in die Windows Ereignisanzeige unter Anwendungs- und Dienstprotokolle/Microsoft/Windows/Backup. Oh je, der Eindruck mit denen von wbadmin stimmt überein, keine Backups wurden für die letzten Wochen protokolliert.

An was liegt es? Ist womöglich die Ausführung in der Aufgabenplanung deaktiviert? Witzig: Nein, die scheint immer schön brav jeden Tag durchzulaufen und meldet keine Fehler!

Gibt es hier einen Masterplan? Keine Ahnung, zunächst kann man natürlich die Ressourcenüberprüfung mittels SFC.EXE /SCANNOW drüberjagen, doch die brachte nichts.

Jetzt sollte man sich mal Gedanken machen, welche Dienste für eine Datensicherung benötigt werden. Da gibt es drei:

PS> Get-Service wbengine, SDRSVC, VSS

Status   Name               DisplayName
——   —-               ———–
Stopped  SDRSVC             Windows-Sicherung
Stopped  VSS                Volumeschattenkopie
Stopped  wbengine           Blockebenen-Sicherungsmodul

stellt sich die Frage, lassen die sich starten?

PS> Start-Service wbengine, SDRSVC, VSS
start-Service : Der Dienst "Windows-Sicherung (SDRSVC)" kann aufgrund des folgenden Fehlers nicht gestartet werden:
Der Dienst SDRSVC kann nicht auf dem Computer . gestartet werden.

In Zeile:1 Zeichen:1
+ start-Service wbengine, SDRSVC, VSS
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service],
   ServiceCommandException
    + FullyQualifiedErrorId : CouldNotStartService,Microsoft.PowerShell.Commands.StartServiceCommand

PS> Get-Service wbengine, SDRSVC, VSS

Status   Name               DisplayName
——   —-               ———–
Stopped  SDRSVC             Windows-Sicherung
Running  VSS                Volumeschattenkopie
Running  wbengine           Blockebenen-Sicherungsmodul

OK, das ist eine Aussage: Der Dienst kann nicht gestartet werden, weil der Dienst nicht gestartet werden kann! Blöd so was, aber warum kann er nicht gestartet werden?

PS> Get-Service SDRSVC | fl *

Name                : SDRSVC
RequiredServices    : {RPCSS}
CanPauseAndContinue : False
CanShutdown         : False
CanStop             : False
DisplayName         : Windows-Sicherung
DependentServices   : {}
MachineName         : .
ServiceName         : SDRSVC
ServicesDependedOn  : {RPCSS}
ServiceHandle       : SafeServiceHandle
Status              : Stopped
ServiceType         : Win32OwnProcess
StartType           : Disabled
Site                :
Container           :

Klar, wenn ein Dienst deaktiviert ist, dann kann er auch nicht gestartet werden!

Also setzen wir den Dienst auf seinen Standardwert:

PS> Set-Service SDRSVC -StartupType Manual

Nun kann man mittels SDClt.EXE oder, wie gewohnt, mit vielen Klicks den Punkt “Sichern und Wiederherstellen” aufrufen und siehe da, es wird wieder alles angezeigt!

Ob dann die Sicherung auch wirklich klappt? Keine Ahnung, aber wer so eine Einstellung hat, der hat vielleicht einen weiteren Dienst deaktiviert, also schauen wir uns noch die anderen Dienste an:

PS> Get-Service wbengine, SDRSVC, VSS| select name, displayname, starttype

Name     DisplayName                 StartType
—-     ———–                 ———
SDRSVC   Windows-Sicherung              Manual
VSS      Volumeschattenkopie            Manual
wbengine Blockebenen-Sicherungsmodul    Manual

Also sieht ja gut aus.

Da wir gerade dabei sind, wenn es schon Probleme gibt, dann helfen diese Abfragen (Powershell 3.0 muss vorhanden sein):

Get-WinEvent -LogName Microsoft-Windows-Backup|select -First 10

Get-ScheduledTask -Recurse | where name -match backup| select name,status,lastruntime,lasttaskresult, nextruntime| ft –AutoSize

Get-Service wbengine, SDRSVC, VSS| select name, displayname, starttype, status

vssadmin list writers

Bei Get-ScheduledTask ist wichtig LastTaskResult mit anzuzeigen, weil dies standardmäßig nicht mit aufgelistet wird aber wertvolle Hinweise geben kann.

Bei vssadmin list writers sind insbesondere die Angaben zum letzten Fehler der einzelnen Writer zu beachten! Eine Idee, wie man mit vssadmin umgeht, geben diese beiden Artikel: https://newyear2006.wordpress.com/2015/12/19/windows-8-1-backup-mit-wbadmin-bricht-mit-fehler-auf-das-bereitgestellte-sicherungsvolume-konnte-nicht-zugegriffen-werden-ab-bzw-fehlercode-0x807800c5/ und https://newyear2006.wordpress.com/2011/09/09/sbs2011-backup-bricht-mit-fehler-2155348129-ab-und-was-hat-das-mit-sharepoint-updates-zu-tun/.

Telekom Speedport W 724V und das Problem mit dem E-Mailversand über SMTP, der blockt einfach alle Benutzerdomains

14 Dezember 2015

Im Grunde ist es ja gut, wenn man für Sicherheit sorgt. Ich verstehe auch, dass die Telekom, als mit größter Anbieter in Deutschland, sich aktiv am Schutz gegen SPAM und Konsorten beteiligt. Aber muss es dann auf dem Rücken der Benutzer, bzw. kleineren Firmen sein?

Der Speedport W 724V kommt scheinbar im Auslieferungszustand mit einer Einstellung, welche sich “Liste der sicheren E-Mail-Server” nennt. Dabei wird jegliche Kommunikation aus dem lokalen Netz von Port 25 und 587 ins Internet blockiert. Sei es Handy oder Computer spielt keine Rolle. Alles was den Speedport als Gateway eingetragen hat und über die SMTP-Ports rausgeht, wird blockiert.

Beim Testen äußert sich das Phänomen dadurch, das keine Telnet-Verbindung auf Port 587 zum Mailserver aufgebaut werden kann. Man verwendet

telnet mailserver.domain 587

Zunächst passiert ewig nichts und nach dem Timeout von ca. 20 Sekunden wird als Fehlermeldung

Verbindungsaufbau zu mailserver.domain…Es konnte keine Verbindung mit dem Host hergestellt werden, auf Port 587: Verbindungsfehler

dargestellt.

Von Erfahrenen Benutzern wird nun zunächst die Firewall oder der Virenscanner als Schuldiger in Betracht gezogen. Aber in diesem Fall ist es wie gesagt der Speedport.

Es werden wirklich auch nur bestimmte Ports geblockt. Wahrscheinlich neben 25 und 587 auch 465, welchen ich aber nicht getestet hatte. DNS-Abfragen und ICMP-Pakete vom Ping gehen jedoch problemlos durch. D. h. ein

ping mailserver.domain

wird klappen auch eine Abfrage bei nslookup liefert den passenden Mailserver.

Die Lösung ist am Ende den zugehörigen mailserver.domain in die Liste der sicheren SMTP-Server des Speedport aufzunehmen. Dabei macht es teilweise auch Sinn, wenn man die IP-Adresse des Servers mit aufnimmt, da diese in der Regel fix ist. Auch muss man teilweise mit Namensvarianten rechnen.

Für unbedarfte Benutzer ist sicher das Abschalten des Punktes im Speedport unter Internet, Liste der sicheren E-Mail-Server und entfernen des Häkchen bei “Liste der sicheren E-Mail-Server verwenden” die einfachste Lösung.

Zum Thema interessant ist noch folgender Thread bei der Telekom: https://telekomhilft.telekom.de/t5/Ger%C3%A4te-Zubeh%C3%B6r/W-724-V-blockt-Zugang-zu-smtp-Server/td-p/1050002

Hier bringt es auch Benutzer @Elgreco1900 schön auf den Punkt:

Ich weiß, wie ich das im Speedport ändern kann. Das ist nicht das Problem.

Das Problem ist, dass ich tätig bin für einen Hosting-Provider, der E-Mail-Dienste anbietet. Wir haben nun massenhaft Annrufe von Kunden, die keine E-Mails mehr versenden können. Die rufen bei uns an, nicht bei der Telekom, Und die sind sauer auf uns, nicht auf die Telekom. Und wir müssen denen dann erklären, wie sie den Speedport der Telekom umkonfigurieren müssen. Und wir müssen ihnen erklären, dass unsere Mailserver sicher sind, auch wenn die nicht auf der Liste der sicheren Mailserver der Telekom stehen. Die Telekom benachteiligt hier die E-Mail-Anbieter, die nicht auf der Liste stehen.

Womöglich sind von dem tollen Feature noch weitere Speedport betroffen: https://telekomhilft.telekom.de/t5/Ger%C3%A4te-Zubeh%C3%B6r/Speedport-W921V-SMTP-blockiert/td-p/464718.

Zum Testen sind diese Artikel hilfreich:
https://newyear2006.wordpress.com/2011/10/01/telnet-auf-die-schnelle-aktiveren-bzw-deaktivieren/
https://newyear2006.wordpress.com/2015/08/22/der-kleine-telnet-client-in-powershell/

Windowsupdate.LOG unter Windows 10 lesen

6 Dezember 2015

MS hat mal wieder ein Zwangsverbesserung angestoßen und damit vieles wieder komplizierter gemacht. Konnte man früher einfach die Windowsupdate.LOG-Datei aus C:\Windows im Notepad einsehen, so findet man nun den Hinweis:

Windows Update logs are now generated using ETW (Event Tracing for Windows).
Please run the Get-WindowsUpdateLog PowerShell command to convert ETW traces into a readable WindowsUpdate.log.

For more information, please visit http://go.microsoft.com/fwlink/?LinkId=518345

Ich kann mir den Grund schon denken, warum die Umstellung gemacht wurde, nämlich wegen Performance und der Dateifragmentierung vorzubeugen. Vor allem auf Windows IoT Geräten ist immer zu wenig Platz, also warum dann nicht ein bewährtes Format verenden, welches eh Log-Dateien im Zaum hält.

Als bekennender Powersheller hab ich auch kein Problem mit Commandlets, aber wenn dann weite Teile der daraus erzeugten Log-Datei dann so aussieht?

1601.01.01 01:00:00.0000000 1040  13164                 Unknown( 10): GUID=fceb5510-7e12-22d8-8d1b-e6a079483552 (No Format Information found).
1601.01.01 01:00:00.0000000 1040  13164                 Unknown( 26): GUID=464bbb57-7e12-b0a1-8d1b-e6a079483552 (No Format Information found).
1601.01.01 01:00:00.0000000 1040  13164                 Unknown( 10): GUID=fceb5510-d1b3-b0a1-23ef-338952442d14 (No Format Information found).

Wo ist hier der Informationsgehalt?

Wenn es nur Teile betrifft, kann man sich mittels dieses Aufrufs eine einfachere Update.Log erstellen:

Get-Content "$env:USERPROFILE\Desktop\Windowsupdate.log"|Select-String -Pattern "1601.01.01 01:00:00.0000000*" -NotMatch |Set-Content "$env:USERPROFILE\Desktop\Windowsupdate_Clean.log"

Damit erhält man die unsinnigen Fragmente ausgefiltert und die relevanten Daten in Windowsupdate_Clean.log gespeichert. Hier bei den Kommentaren lassen sich einige zum Thema aus: https://technet.microsoft.com/en-us/library/mt238376.aspx.

Leider hat auch Windows 10 V1511 das Problem mit den falschen bzw. unnötigen LOG-Einträgen.

Wer jetzt denkt, er wäre clever und könnte direkt die Inhalte aus den EWT-Dateien auslesen, denn schließlich gibt es ja noch die Funktion Get-WinEvent, welche EWT-Dateien lesen kann, wird ernüchtert feststellen, dass dem nicht so ist. Der Inhalt der mittels EWT erfassten Daten wird in Dateien mit der Endung .ETL gespeichert.

Beim Aufruf von z. B.

Get-WinEvent -Path C:\Windows\logs\WindowsUpdate\WindowsUpdate.20151206.160438.596.1.etl -Oldest

bekommt man genauso das belanglose Geschwafel wie in der erzeugten Windowsupdate.LOG-Datei. Ist das womöglich ein genereller Bug?

Ein weiterer Artikel zum Format und was man damit machen kann und wo auch auf den Symbolserver eingeht: http://blogs.technet.com/b/charlesa_us/archive/2015/08/06/windows-10-windowsupdate-log-and-how-to-view-it-with-powershell-or-tracefmt-exe.aspx.

Was gibt der Registrierungsschlüssel DHCPGatewayHardware her? Oder – wie kann man alternativ per Powershell das DHCP-IPv4-Gateway ermitteln?

28 September 2015

Hier mal etwas für Forensiker. Aus der Not geboren, dass nur eine Fernwartung beim Kunden möglich war – die nur einmal aufgebaut werden konnte, galt es herauszufinden, warum Netzprobleme bei der IPv4-Adressvergabe auftraten. Eigentlich sollten die Clientrechner IP-Adressen im Bereich 192.168.0.X bekommen aber effektiv bekamen fast alle Rechner eine im Bereich 192.168.1.X. Dadurch war kein Internetzugang mehr möglich und auch der Fileserver unter 192.168.0.1 war nicht mehr erreichbar. Da im konkreten Fall ein Speedport mit der Adresse 192.168.0.100 der DHCP-Server war, wurde zunächst eine Station mit einer fixen IP-Adresse im Bereich des Speedport versehen. Von dort aus war dann der Zugriff zum Speedport möglich. Auch das Internet mit einer Fernwartungssitzung klappte dadurch wieder. Jetzt galt es aber rauszubekommen, warum die Rechner teilweise falsche IP-Adresse bekamen. Nur wie macht man das, wenn man auf der einzigen Netzwerkkarte per Fernwartung aufgeschaltet ist?

Zunächst versuchte ich Scapy per Python ans laufen zu bekommen,  um dieses Script ausführen zu können: https://bitbucket.org/secdev/scapy/wiki/doc/IdentifyingRogueDHCPServers. Die Idee war ganz einfach einen Netzwerkmitschnitt über DHCP-Server-Ankündigungen zu machen. Aber leider beschwerte sich Scapy, beim Versuch der Installation, ständig über eine weitere, fehlende Abhängigkeit. Am Ende lief es auf jeden Fall nicht.

Wireshark wäre noch eine Option gewesen, da die WinPCap-Treiber wegen Scapy eh schon installiert waren. Aber Wireshark kann jeder.

Wie immer wäre mir eine Powershell-Lösung die liebste, aber leider gibt es noch nichts Vergleichbares zu Scapy. Bei der Suche nach der Powershell-Lösung bin ich allerdings über diesen Artikel gestolpert: http://www.ingmarverheij.com/read-dhcp-options-received-by-the-client/. Ich hatte zwar beim betreffenden Windows 7 Rechner keinen Eintrag mit DhcpInterfaceOptions aber zumindest der Eintrag DhcpGatewayHardware war vorhanden. Der Eintrag war als REG_BINARY mit dem Wert

c0 a8 01 01 06 00 00 00 e8 fc af ab c0 24

eingetragen. Der Wert von DhcpGatewayHardware ist zu finden unter HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{GUID}.

Per Powershell erreicht man den Wert über

$a = gwmi Win32_NetworkadapterConfiguration
$i = $a | where {$_.Description –like "*Intel*"}

$i.SettingID

$si = $i.SettingID

$ri = Get-ItemProperty -path "registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\$si" -name dhcpgatewayhardware | select DHCPGatewayHardware

$ri

Bei *Intel* sollte man den Hersteller seiner Netzwerkarte eintragen, für Realtek z. B. *Realt*, wenn es mehrere geben sollte, muss natürlich die betreffende herausgefiltert werden. Das entscheidende dabei ist, dass man die GUID der SettingID bekommt, über welche man weiß wo man in der Registrierung bei den Interfaces suchen muss.

Auf jeden Fall bekommt man am Ende bei $ri z. B.  diese Ausgabe:

DhcpGatewayHardware
——————-
{192, 168, 1, 1…}

Man sieht bereits, dies ist der falsche Wert, der am Anfang dafür gesorgt hatte, dass der Kunde nicht arbeiten konnte. Das interessante dabei ist, 192.168.1.1 entspricht hexadezimal genau “c0 a8 01 01”, die grüne Markierung verdeutlicht nochmal den Zusammenhang. Also ist der Zusammenhang schon mal hergestellt. Der hintere Wert e8 fc af ab c0 24 sieht wie eine MAC-Adresse aus, denn warum sonst sollte Microsoft den Eintrag DhcpGatewayHardware nennen?

Also noch die Bytes 8-14 ausgelesen und daraus eine MAC-Adresse gebastelt:

$mac=$ri.DhcpGatewayHardware[8..14]
$mac=$mac| foreach {$new=""} {$new+="{0:x02}:" -f $_} {$new}
$mac=$mac.TrimEnd(":")

$mac

Nun hat man in $mac die MAC-Adresse des DHCP-Servers, welcher die IP-Adresse 192.168.1.1 geliefert hatte.

Also mal Google bemüht und dies gefunden: http://macaddress.webwat.ch/hwaddr/E8:FC:AF. Hier wird E8:FC:AF Netgear zugeordnet:

Device mac address: E8:FC:AF
Base16 encoding: E8FCAF
producer name: NETGEAR INC.,

producer address:

350 EAST PLUMERIA DRIVE
SAN JOSE CALIFORNIA 95134
UNITED STATES

Jetzt galt es nur noch ein Gerät ausfindig zu machen. Aber mit dem Wissen, dass es sich um ein Netgear Gerät handelte, war der weitere Weg wesentlich einfacher, als wenn es irgendein Gerät im Netz gewesen wäre. Vor allem war dadurch auch klar, dass es sich nicht um einen gefakten bzw. Rogue-DHCP-Server handelte, welcher eine Attacke im Netz ritt.

Übrigens: Bei einem korrekt konfigurierten und funktionierendem Netz bekommt man, bei Anwendung obigen Scripts, einfach das Gateway mit der betreffenden MAC-Adresse, wenn DHCP aktiviert ist.

CHKDSK Ergebnisse per Powershell auslesen

17 September 2015

Wenn man ChkDsk auf Laufwerk C: eines Windows Rechners anwendet, wird man meist gefragt, ob man beim nächsten Neustart die Prüfung durchführen möchte. Soweit kein Problem. Nur muss man sich nach der Prüfung die passende Log-Datei heraussuchen, mit GUI mitteln wie immer mühsam, deshalb hier ein kleiner Powershell-Einzeiler, der die CHKDSK-Einträge auflistet:

Get-WinEvent -FilterHashtable @{logname="Application"; id="1001"}| where providername -eq Microsoft-Windows-WinInit | fl *

Wer sich für die vergangenen Prüfungen interessiert, der wird wahrscheinlich eher im “System Volume Information”-Verzeichnis, dort speziell im Chkdsk-Verzeichnis fündig. Dort gibt es z. B.

Chkdsk20150917130104.log

welche man sich per Powershell mittels

Get-Content .\Chkdsk20150917130104.log -Encoding Unicode

anschauen kann.

Um auf System Volume Information zugreifen zu können, benötigt man allerdings spezielle Rechte! Näheres hier: https://support.microsoft.com/en-us/kb/309531. Davon die Kurzfassung als Admin:

icacls "C:\System Volume Information" /E /G Admin:F

Wer sich für die reine Powershellfassung für ICACLS interessiert, wird hier fündig: http://blogs.technet.com/b/josebda/archive/2010/11/09/how-to-handle-ntfs-folder-permissions-security-descriptors-and-acls-in-powershell.aspx sowie http://blogs.msdn.com/b/johan/archive/2008/10/01/powershell-editing-permissions-on-a-file-or-folder.aspx.

Für was das “System Volume Information”-Verzeichnis alles herhalten muss: http://blogs.msdn.com/b/oldnewthing/archive/2003/11/20/55764.aspx.