Archive for November 2010

QNAP NAS verliert Freigaben auf den ersten Blick sogar Daten

18 November 2010

Oh Schreck nach gewaltsamen Ausschalten waren die Daten weg! Falls es mal wieder passiert, hier ein paar Tipps:

Es waren nur die Shares weg und nach dem die passenden Shares angelegt wurden, war alles wieder OK.

Leider hatte ein “Restore Default Network Shares” nichts gebracht. Ein Blick mit Telnet auf das NAS forderte dann aber doch alle Verzeichnisse auf dem ursprünglich angelegten RAID zu Tage. Auch der Befehl df (http://de.wikibooks.org/wiki/Linux-Kompendium:_df) zeigt, das noch der ganze Platz belegt ist und forderte auch gleich noch zutage, dass das Volume gemountet war.

Dieser Artikel war die Grundlage: http://forum.qnap.com/viewtopic.php?f=22&t=35290

Probleme mit Druckertreibern und Windows 7 und Server 2008 R2 lösen

17 November 2010

Wem ein schlecht programmierter Druckertreiber mit zu vielen unnützen Funktionen das Leben schwer macht und regelmäßig die Druckerwarteschlange runterzieht, der wird sich über die Möglichkeit der Druckertreiberisolation freuen:

http://blogs.technet.com/b/askperf/archive/2009/10/08/windows-7-windows-server-2008-r2-print-driver-isolation.aspx

Damit hat jeder Treiber seinen eigenen Prozess und kann sich darin austoben. Ein Crash sorgt dann nur davon dass die betreffende PrintIsolationHost.EXE abstürzt.

Hier noch einige Interessante Infos von HP und deren UPD mit Isolated Unterstützung: http://h20338.www2.hp.com/hpsub/downloads/
UPD_Microsoft_Driver_Isolation_Mode.pdf

Microsoft Hyper-V Server in Arbeitsgruppe aufnehmen

17 November 2010

Einen Microsoft Hyper-V Server in eine Arbeitsgruppe aufzunehmen ist keine triviale Sache.

Hier werden die nötigen Schritte beschrieben: http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/11/configuring-remote-management-of-hyper-v-server-in-a-workgroup.aspx

Acrobat Reader startet nicht wegen Problem mit HP ToolboxFX

16 November 2010

Beim Versuch PDF-Dateien zu öffnen öffnete sich der Acrobat Reader nicht (hier Version 9.4). Nachdem das Phänomen ein paar Mal aufgetreten war und nie klar war, warum das ganze passiert, brachte eine eingehende Analyse den Schuldigen zum Vorschein: Die HP ToolboxFX. Der betreffende Rechner war mit einem Deskjet Drucker von HP ausgestattet.

Immer wenn der Acrobat Reader gestartet wird, wollte sich dieser natürlich auch über die vorhandenen Drucker schlau machen. Also wurden die üblichen WINSPOOL API-Aufrufe eingeleitet. Doch bei diesen Aufrufen muss der HP ToolboxFX irgendwas quer gelaufen sein.

Anstatt nun aber Meldung zu machen, scheint die HP-Toolbox abgestürzt zu sein und hat es nicht geschafft dies kund zu tun. Bei diesem Vorgang hat sie gleich noch die Druckerwarteschlange vom Betriebssystem (hier Vista) mit lahmgelegt.

Durch die Analyse mittels Sysinterals Process Explorer wurde der Aufruf von WINSPOOL Funktionen entdeckt, weshalb als erste Reaktion einfach mal der Druckerwarteschlangendienst neu gestartet wurde. Genau hier kam die Wendung. Als der Dienst nicht beendet werden konnte, ging im Hintergrund plötzlich die Meldung der HP Toolbox FX auf:

HP ToolboxFX hat einen Fehler festgestellt und kann nicht wiederhergestellt werden.

Starten Sie HP ToolboxFX oder Ihren Computer neu. Sie können keine Meldungen empfangen. Verwenden Sie alternativ dazu andere HP ToolboxFX-Funktionen, bis HP ToolboxFX neu gestartet wurde.

Windows-Version: Win32NT – 6.0.6002.0 HP ToolboxFX Version: 002.005.00191

In der englischen Fassung lautet die Meldung:

HP ToolboxFX has encountered an error and can not recover.

Please re-start HP ToolboxFX, or re-start your PC. You will not be able to receive alert messages, or use other HP ToolboxFX features until HP ToolboxFX has been restarted.

Windows version: Win32NT – 5.1.2600.0
HP ToolboxFX version: 002.005.00191

In einem anderen Fall war die Version von ToolboxFX 004.012.00146. Die Version 004.012.00146 ist angeblich die neueste Version. Danach war auf einmal alles gut!

Also wer ist Schuld? Hewlett Packard, die es einfach nicht mehr gebacken bekommen vernünftige Treiber auf die Beine zu stellen. Wo wir gerade beim Thema HP sind: Es ist grauenhaft da nach Treibern für Geräte zu suchen die gerade mal 2 Jahre alt sind. Irgendwelche Möchtegerns haben bei einer Systemumstellung alles möglich an sinnvollen Informationen ins Nirwana geschickt. Keine Treiber mehr, keine Handbücher mehr, keine Spezifikationen. Ein einziges Durcheinander. Selbst ein Anruf an der Hotline bringt nur ein: Ja wissen wir. 64Bit Treiber? Was ist das?

Es ist kein Ende in Sicht.

Frühere Beitrage mit HP Beteiligung:

https://newyear2006.wordpress.com/2010/05/03/hp-universal-printer-driver-upd-druckertreiber-macht-probleme-unter-windows-7/

https://newyear2006.wordpress.com/2008/11/18/usb-hp-drucker-taucht-nicht-unter-windows-vista-auf/

Terminalserver Lösung bei Drucker oder Scannerproblemen

16 November 2010

http://www.2x.com/blog/2010/05/virtualization/2x-universal-printing-and-scanning/

Geniale Icons vor allem mit vielen Erklärungen

15 November 2010

Ein unendliche Übersicht von Icons und Tutorials zur Herstellung bzw. Verwendung: http://iconlibrary.iconshock.com/ bzw. http://www.iconshock.com/

Frühere Iconlinks:
https://newyear2006.wordpress.com/2010/07/22/interessante-icon-sets/

Offline Transfer von Windows Dateien mittels USMT und WinPE

12 November 2010

Dieses Dokument beschreibt Schritt für Schritt wie man Daten eines Offlinesystem per WinPE mittels USMT übernehmen kann:

http://technet.microsoft.com/en-us/library/ee126219(WS.10).aspx

Hier noch einige Hinweise und mögliche Fehlerbeschreibungen mit Lösungen: http://blogs.technet.com/b/askds/archive/2010/02/18/usmt-4-and-winpe-common-issues.aspx

Hier die normale Beschreibung: http://technet.microsoft.com/en-us/library/dd560758(v=WS.10).aspx

Beschreibung was alles mitgenommen wird: http://technet.microsoft.com/en-us/library/dd560792(WS.10).aspx#BKMK_4

Wenn die Übernahme nicht klappt, fehlen vielleicht die Manifestdateien: http://blogs.technet.com/b/askds/archive/2010/08/25/don-t-mess-about-with-usmt-s-included-manifests.aspx

Windows Firewall mit Erweiterter Sicherheit debuggen von DROP Paketen

12 November 2010

Wenn es mal wieder nicht klappt mit dem Zugriff von einem entfernten Rechner auf Netzwerkressourcen könnte es an der Windows Firewall liegen. Vorhanden ab Windows Vista.

Zuerst muss man mal rausfinden ob dem so ist.

Man startet also die Windows Firewall mit erweiterter Sicherheit (WF.MSC).

Dort schaut man dann zuerst welches Profil aktuell aktiv ist und klickt dann auf “Windows-Firewalleigenschaften” oder man klickt links im Baum auf den obersten Eintrag mit der rechten Maustaste und geht auf Eigenschaften.

Es öffnet sich ein Dialog mit Registern für jedes Profil. Hier klickt man nun auf das aktuell aktive Profil. Nun kann man bei Protokollierung durch klick auf Anpassen den Pfad sowie die Einstellungen dafür verändern.

Hier sollte man sich nun mindestens den Pfad für die Logdatei merken und die Protokollierung von verworfenen Paketen aktivieren. Der vorgebene Pfad lautet:

C:\Windows\system32\LogFiles\Firewall\pfirewall.log

Nun werden die verworfenen Pakete in der LOG-Datei gespeichert, allerdings muss man teilweise ein paar Sekunden warten bis die Daten in der LOG-Datei auftauchen.

Verworfene Pakete sehen dann so aus:

2010-11-12 18:44:51 DROP TCP 192.168.10.22 192.168.10.20 54745 8624 48 S 1684385589 0 65535 – - – RECEIVE
2010-11-12 18:45:07 DROP TCP 192.168.10.22 192.168.10.20 54745 8624 48 S 1684385589 0 65535 – - – RECEIVE
2010-11-12 18:47:47 DROP TCP 192.168.10.22 192.168.10.20 54747 8624 64 S 1346924637 0 65535 – - – RECEIVE

Tolle Sache. Hier die Beschreibung des Formats: http://technet.microsoft.com/en-us/library/cc753781(v=WS.10).aspx. Aber den Grund warum die Pakete verworfen wurden, der wird einem nicht mitgeteilt.

OK, als erstes sollte man auf dem betreffenden Server Rechner erst prüfen ob die betreffende Serveranwendung überhaupt läuft:

netstat –an

hilft. Dort sollte bei der lokalen Adresse 0.0.0.0 mit dem passenden Port stehen und der Status sollte ABHÖREN lauten.

Tiefergehende Infos bekommst man als Admin mittels

netstat –p TCP –abn

Dann werden die Prozesse angezeigt ebenso findet eine Einschränkung des Protokolls auf TCPv4 statt.

Mittels Event Tracing kann man das Spiel nun weiter treiben und noch tiefer schauen. Das Event Tracing ist eine ziemlich mächtige Sache. Hier bin ich schon mal darauf eingegangen in Verbindung mit USB: https://newyear2006.wordpress.com/2009/12/27/usb-probleme-in-windows-7-analysieren-und-verstehen/

Man kann sich tiefergehende Infos mittels netsh mitschneiden. Dazu startet man

netsh wfp

Dieser Befehl startet die Netzwerkshell und wechselt zum WFP Kontext welcher für Windows-Filter-Platform steht, welche für das inspizieren der Pakete zuständig ist.

Hier kann man nun das Aufzeichnen von Paketen mittels

capture start

aktivieren. Alle Pakete die nun empfangen werden, werden nun gespeichert und in die Datei WFPDiag.CAB im aktuellen Verzeichnis abgelegt wenn man den Befehl

capture stop

eingibt.

Die Datei WFPDiag.CAB enthält dann zwei Dateien die WFPDiag.ETL und WFPDiag.XML. Die XML-Datei kann man sich dann direkt anschauen und findet so interessante Einträge wie:

- <netEvent>
- <header>
  <timeStamp>2010-11-12T16:03:08.836Z</timeStamp>

- <flags numItems="8">
  <item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>

  <item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>

  <item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>

  <item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>

  <item>FWPM_NET_EVENT_FLAG_REMOTE_PORT_SET</item>

  <item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>

  <item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>

  <item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>

  </flags>

  <ipVersion>FWP_IP_VERSION_V4</ipVersion>

  <ipProtocol>6</ipProtocol>

  <localAddrV4>192.168.10.20</localAddrV4>

  <remoteAddrV4>192.168.10.22</remoteAddrV4>

  <localPort>8624</localPort>

  <remotePort>54619</remotePort>

  <scopeId>0</scopeId>

- <appId>
  <data>530079007300740065006d000000</data>

  <asString>S.y.s.t.e.m…</asString>

  </appId>

  <userId>S-1-5-18</userId>

  </header>

  <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>

- <classifyDrop>
  <filterId>74004</filterId>

  <layerId>44</layerId>

  <reauthReason>0</reauthReason>

  <originalProfile>2</originalProfile>

  <currentProfile>2</currentProfile>

  </classifyDrop>

  </netEvent>

Ist leider etwas unformatiert. Aber hier finden sich die gesuchten Informationen wieder: Die IP-Adresse des anfragenden Computers 192.168.10.22 und die des lokalen Computers mit 192.168.10.20 wo Port 8624 angesprochen werden soll.

Der Zweig mit ClassifyDrop enthält noch weitere Hinweise:

- <classifyDrop>
  <filterId>74004</filterId>

  <layerId>44</layerId>

  <reauthReason>0</reauthReason>

  <originalProfile>2</originalProfile>

  <currentProfile>2</currentProfile>

  </classifyDrop>

Die Struktur wird in http://msdn.microsoft.com/en-us/library/ee707311(v=VS.85).aspx näher erläutert.

Entscheidend ist die LayerID 44  welche auf FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4 weiter oben in der XML-Datei zeigt. Übersicht der Filter: http://msdn.microsoft.com/en-us/library/aa366492(v=VS.85).aspx

Manchmal kann es helfen so tief ins System Einblick zu bekommen. Im konkreten Fall brachte es aber nichts. Erst als anstatt IIEXPRESS.EXE explizit der zugehörige Port 8624 per neuer Firewallregel geöffnet wurde, hat es funktioniert.

Den einen oder anderen Hinweis für die Innereien der Filterplattform findet man auch im Entwicklerforum: http://social.msdn.microsoft.com/forums/en-US/wfp/threads/

netsh http add urlacl und SDDL Fehler 1332

12 November 2010

Weil ich jetzt schon zwei Mal darauf reingefallen bin. Um z. B. beim IIS unter Windows 7 (gilt eigentlich ab Vista und für Server) etwas umzukonfigurieren, muss netsh http bestimmte Rechte vergeben.

Wenn man z. B.

netsh http add urlacl url=http://mypc:8080/ user=everyone

verwendet wie oft in Dokumentationen angegeben, so bekommt man den netten Fehler

Die SDDL konnte nicht erstellt werden. Fehler: 1332
Falscher Parameter

Hä? Wie bitte? Habs beim ersten Mal mehrmals überprüft!

Die Lösung:

netsh http add urlacl url=http://mypc:8080/ user=Jeder

Im Prinzip logisch, aber sowas sollte seit Vista und der internen Umstellung auf Englisch + MUI nicht mehr sein. Danke MS!


Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.