Archive for the ‘Problemlöser’ Category

Fehlende Rechte bei Standardbenutzer zur Konfiguration von Geräte-Manager oder Modemoptionen unter Windows 8

23 Juli 2014

Auf einer aktuellen Windows 8.1 Maschine musste ein Callbridge TAPI Treiber installiert werden. Abgesehen vom ganzen Vorspiel, dass wegen eines Bugs von Microsoft bzw. eine Änderung der TAPI-API bei Windows 8.1 64-Bit, eine komplette neue Telefonanlage nötig war, sollte nur ein TAPI Treiber konfiguriert werden.

Nach der Treiberinstallation wurde unter der Systemsteuerung Modem und Telefonoptionen aufgerufen sowie das Register Erweitert. Hier kann man üblicherweise Konfigurieren anklicken, damit man die betreffenden zusätzlichen Einstellungen vornehmen kann. Leider war dies immer ausgegraut. Denn der angemeldete Benutzer ist nur Standardbenutzer. Ist ja eigentlich kein Problem aber obwohl bei der Konfigurationsschaltfläche das Schild für die höheren Adminrechte angezeigt wurde, wurde nie nach den Adminrechten gefragt. Jeder Klick wurde großzügig ignoriert.

Dies äußert sich auch an viel prominenterer Stelle. Klickt man auf System und dann auf Geräte-Manager, erscheint dies:

—————————
Geräte-Manager
—————————
Sie sind als Standardbenutzer angemeldet. Dies ermöglicht Ihnen zwar das Anzeigen von Geräteinstellungen im Geräte-Manager, zum Vornehmen von Änderungen müssen Sie jedoch als Administrator angemeldet sein.
—————————
OK  
—————————

Dabei war davor am Link auch noch das Zeichen mit dem Schild zu sehen, wo normalerweise nach Adminrechten gefragt wird. Aber das interessiert halt nicht.

Wieder mal typisch MS Chaos. Was tun?

Diese Liste verzeichnet Programme die man direkt aufrufen kann: http://newyear2006.wordpress.com/2008/02/08/direktstartprogramme-unter-windows-vista-und-windows-xp/. Unter anderem gibt es hier telephon.cpl. Genau das wird benötigt aber mit mehr Rechten, also:

C:\>runas /profile /user:pc\admin "cmd.exe /c start telephon.cpl"
Geben Sie das Kennwort für "pc\admin" ein:
Es wird versucht, cmd.exe /c start telephon.cpl als Benutzer "rms\admin" zu starten…

Trommelwirbel: Das wars. Damit war Konfigurieren anklickbar. OK, das war die komplizierte Lösung. Es reicht eigentlich wenn man eine Eingabeaufforderung als Admin aufmacht und dann

start telephon.cpl

oder

devmgmt.msc

für den Gerätemanager aufruft.

Windows Drucker will nicht mehr und beim Versuch eine Testseite auszudrucken erscheint Fehlernummer 0×00000006

23 Juli 2014

Ein Kunde meldet sich und meint, sein Drucker druckt nicht mehr. Jetzt kann dies wie immer viele Ursachen haben aber diese ist mal wieder typisch Microsoft. Der Kunde hat ein kleines Netzwerk und somit eine Domäne. Der Drucker wird vom Server verwaltet und ist per Netzwerk dem Client zugeordnet.

Wie gesagt druckt der jetzt nicht mehr. Also die übliche Prozedur mit zunächst Windows-Testseite drucken, um rauszufinden, ob es ein Windows bzw. Treiberproblem ist oder von der Anwendung herrührt.

Mmhh. Windows-Testseite drucken meldet:

[Window Title]

Druckereigenschaften

 

[Main Instruction]

Die Testseite konnte nicht gedruckt werden. Soll die Druckproblembehandlung angezeigt werden? Der Vorgang konnte nicht abgeschlossen werden (Fehler 0×00000006).

 

[Ja] [Nein]

Dasselbe nochmal als Admin probiert half auch nichts. Nett wie Windows ist, bietet es einem die Druckproblembehandlung an. Aber alles was die fabriziert ist: Der Drucker ist nicht der Standarddrucker, soll dies geändert werden? Was hat dies mit dem Fehler zu tun? Nichts! Also wie immer ignorieren und selber den Fehler ausfindig machen.

Zunächst war der Gedanke, vielleicht liegt es am Druckertreiber, also Druckerwarteschlange neu gestartet aber wieder nichts. OK, vielleicht der Treiber selber, Rechner neu gestartet, brachte auch nichts. OK, dann vielleicht mal direkt am Server eine Testseite ausdrucken. Klappt!

Na toll. Der Drucker druckt vom Server aber nicht von der betreffenden Station. Also Netzwerkproblem aber welches?

Also mal Powershell aufgerufen und Test-ComputerSecureChannel probiert:

PS C:\Windows\system32> Test-ComputerSecureChannel

Test-ComputerSecureChannel : Der lokale Computer ist keiner Domäne beigetreten,

 oder die Domäne kann nicht kontaktiert werden.

Bei Zeile:1 Zeichen:27

+ Test-ComputerSecureChannel <<<<

    + CategoryInfo          : NotSpecified: (:) [Test-ComputerSecureChannel],

   ActiveDirectoryObjectNotFoundException

    + FullyQualifiedErrorId : System.DirectoryServices.ActiveDirectory.ActiveD

   irectoryObjectNotFoundException,Microsoft.PowerShell.Commands.TestComputer

  SecureChannelCommand

 

Aha, also ein Problem mit der Domänenkommunikation. Zur Bestätigung noch ein w32tm /monitor abgesetzt:

GetDcList ist fehlgeschlagen mit Fehlercode: 0x8007054B.
Beendet mit Fehler 0x8007054B

 

OK.

 

Übrigens ist das Cmdlet Test-ComputerSecureChannel die optimale Hilfe um Probleme mit der Vertrauensstellung zur Domäne (trust relationship) herauszufinden. Nichts mehr wie früher mit NETDOM, wo man zuerst immer schauen musste, wo man es herbekommt. Test-ComputerSecureChannel ist ab PS 2.0 enthalten, also quasi überall. http://technet.microsoft.com/en-us/library/hh849757.aspx.

 

Grund

Ein Vergleich der Uhrzeit zwischen Server und Client offenbarte dann auch schnell den Grund. Der Client hinkte 7 Minuten hinterm Server her!

Ja dann ist ja die Lösung einfach. Zeit gesetzt und Rechner gebootet, neu angemeldet und immer noch der Fehler. Mist.

Wieder Powershell angeworfen und Reset-ComputerMachinePassword probiert:

PS C:\Windows\system32> Reset-ComputerMachinePassword -Server server
Reset-ComputerMachinePassword : Der lokale Computer ist keiner Domäne beigetret

en, oder die Domäne kann nicht kontaktiert werden.

Bei Zeile:1 Zeichen:30

+ Reset-ComputerMachinePassword <<<<  -Server server

    + CategoryInfo          : NotSpecified: (:) [Reset-ComputerMachinePassword

   ], ActiveDirectoryObjectNotFoundException

    + FullyQualifiedErrorId : System.DirectoryServices.ActiveDirectory.ActiveD

   irectoryObjectNotFoundException,Microsoft.PowerShell.Commands.ResetCompute

  rMachinePasswordCommand

Komisch immer diese Fehlermeldungen. In einem anderen Fall hatte dies problemlos zum Erfolg geführt, warum hier nicht? Auf dem anderen Rechner war allerdings Powershell 3.0, in diesem Fall war nur 2.0 installiert.

Lösung:
Also noch Powershell 4.0 von http://www.microsoft.com/de-de/download/details.aspx?id=40855 installiert. Danach war alles gleich viel freundlicher:

PS C:\Windows\system32> Test-ComputerSecureChannel
False
PS C:\Windows\system32> Reset-ComputerMachinePassword -Server server –Credential (Get-Credential)
Cmdlet Get-Credential an der Befehlspipelineposition 1
Geben Sie Werte für die folgenden Parameter an:
Credential
PS C:\Windows\system32> Test-ComputerSecureChannel
False

So jetzt nochmal einen Neustart und alles war gut:

PS C:\Windows\system32> Test-ComputerSecureChannel
True
PS C:\Windows\system32> w32tm /monitor
SERVER.thiel.local *** PDC ***[192.168.16.1:123]:

    ICMP: 0ms Verzögerung

    NTP: +0.0000000s Offset von SERVER.thiel.local

        RefID: (unbekannt) [0xCE383741]

        Stratum: 3

[Warnung]

Die Reversenamenauflösung ist die beste Möglichkeit. Sie ist ggf. nicht

korrekt, da sich das Ref-ID-Feld in Zeitpaketen im Bereich von

NTP-Implementierungen unterscheidet und ggf. keine IP-Adressen verwendet.

PS C:\Windows\system32>

Fazit: Es ist halt immer wieder dasselbe Spiel, sobald Zeitdifferenzen größer 5 Minuten passieren, dann geht das Vertrauen verloren und es kommen die verrücktesten Fehlermeldungen zustande.

Noch ein paar Links mit weiteren Hinweisen:

http://www.techiesweb.com/repair-broken-windows-trust-relationship-between-domain-controller-and-client-machine/

http://www.implbits.com/about/blog/tabid/78/post/don-t-rejoin-to-fix-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/default.aspx

http://blog.joeware.net/2012/06/05/2508/

http://www.cievo.sk/2012/02/21/reset-computer-accounts-in-active-directory-domain/

Gruppierung bei Windows Druckern aufheben

9 Juli 2014

Wenn man unter Windows 7 oder 8 die “Geräte und Drucker” anzeigen lässt, dann stellt Windows Geräte, die denselben Treiber und denselben Port verwenden aber unterschiedliche Namen haben, alle gruppiert in einem Objekt dar.

Bei Problemen kann dies aber hinderlich sein. Mittels dieser Powershell Zeilen wird im Temp-Verzeichnis, welches auch angelegt wird, falls es nicht vorhanden sein sollte ein Symbol mit Drucker angelegt, welches dann den Zugang zu den Druckern erlaubt:

New-Item -ItemType Directory -Name "C:\Temp\Drucker.{2227A280-3AEA-1069-A2DE-08002B30309D}"
Invoke-Item C:\Temp

OK, vielleicht etwas übers Ziel rausgeschossen. Es geht auch einfacher, man gibt in der oberen Adresszeile eines Windows Explorers dies ein und erhält dann auch die Darstellung der Drucker.

shell:::{2227A280-3AEA-1069-A2DE-08002B30309D}

Oder einfach direkt von der Eingabeaufforderung:

start "" "shell:::{2227A280-3AEA-1069-A2DE-08002B30309D}"

stellt eine sogannte ClassID dar, von der es noch mehrere gibt, z. B. stellt diese ClassID die Systemsteuerung dar:

shell:::{21ec2020-3aea-1069-a2dd-08002b30309d}

Eine Auflistung der möglichen Werte findet man hier: https://code.google.com/p/libfwsi/wiki/ShellFolderIdentifiers

In diesem Zusammenhang auch noch interessant: http://newyear2006.wordpress.com/2013/01/19/windows-8-godmode/ 

Der genaue Hintergrund wird hier beleuchtet: http://msdn.microsoft.com/en-us/library/cc144096(VS.85).aspx#virtual

Adobe Reader Installation meldet “Umgültiges Laufwerk…” und bricht die Installation ab

3 Juli 2014

Ein interessantes Konstrukt trat bei dem Versuch den Acrobat Reader Version XI (11.0.07) zu installieren auf. Die Installation brach jedes mal mit der Fehlermeldung

Umgültiges Laufwerk: N:\ ist einem Benutzerordner zugeordnet. Das Laufwerk existiert nicht oder konnte nicht verbunden werden. Trennen Sie das Laufwerk ab oder weisen Sie den Laufwerksbuchstaben neu zu. Weitere Details siehe http://kb2.adobe.com/cps/404

Mal abgesehen von der falschen Rechtschreibung mit Umgültiges anstatt Ungültiges, wäre es hilfreich gewesen den Link korrekt lesen zu können. Leider bringt auch ein STRG+C die Meldung nicht in die Windowszwischenablage.

Nach einigem Suchen wurde dann aber klar, dass der Link auf folgenden Artikel verweist: http://helpx.adobe.com/creative-suite/kb/install-error-1327-invalid-drive.html.

Hier ist genau das tatsächliche Problem beschrieben, dass ein vom Benutzer zugeordneter Laufwerksbuchstabe mit Adminrechten nicht zur Verfügung steht und wenn man dies nachholt, dass es dann auf einmal klappt.

Im Zusammenhang der Problemlösung bin ich auch noch über einen Adobe Reader Cleaner Tool gestolpert: http://labs.adobe.com/downloads/acrobatcleaner.html. Dies hatte aber zur Lösung nichts beigetragen.

Zunächst daran interessiert, die Installation manuell aufzurufen, sind noch folgende Dinge zum Adobe Reader aufgetaucht:

Der Adobe Reader braucht deswegen immer solange bei der Installation weil, z. B. aktuell bei der Version 11.0.0.7 zuerst eine Grundinstallations-MSI der Version 11.0 vom 14.10.2012 verwendet wird, darauf wird eine Patchdatei angewendet, welche erst die aktuellen Dateien enthält und diese wird dann letztendlich mittels MSIEXEC installiert. Hier kann man die verschiedenen Versionen einsehen: http://www.adobe.com/support/downloads/product.jsp?product=10&platform=Windows, wobei der Full-Download immer nur die Grundinstallation darstellt.

Dieser Forenbeitrag https://forums.adobe.com/message/5133118 gibt auch einige erhellende Infos, wie die EXE-Datei entpackt werden kann und dann selber mit den Paketen von der Downloadseite verändert werden kann, wie man vor allem es auch selber hinbekommt Silent Installation durchzuführen

Will man z. B. die aktuelle Version zerlegen ruft man

AdbeRdr11007_de_DE.exe –sfx_o"C:\temp\adobe" –sfx_ne

auf und man bekommt in C:\temp\adobe die MSI und Patchdateien entpackt.

Ansonsten könnte bei Problemen noch die Datei AdobeSFX.log im Temp-Verzeichnis helfen.

Gefährliche NAS-Backups mit Windows 7, Windows 8, Windows 8.1 sowie Server 2008 R2, Server 2012 und Server 2012 R2 und Fehlercode 0xC03A0005 mit Meldung “Die Version unterstützt diese Version des Dateiformats nicht”

28 Januar 2014

Gerade aufgeschreckt durch den Fehler bei einem Kunden auf einem QNAP-NAS während eines Systembackups:

Fehler bei der um ‎2014‎-‎01‎-‎27T21:17:26.330867400Z gestarteten Sicherung. Fehlercode: "0xC03A0005" (Die Version unterstützt diese Version des Dateiformats nicht.). Suchen Sie in den Ereignisdetails nach einer Lösung, und führen Sie die Sicherung erneut aus, nachdem das Problem behoben wurde.

Das Problem wurde bereits im Zusammenhang mit Windows Server 2008 R2 und Windows 7 im November 2010 beschrieben: http://blogs.technet.com/b/asiasupp/archive/2010/11/03/windows-server-backup-failed-with-error-quot-the-version-does-not-support-this-version-of-the-file-format-quot.aspx. Kurz: Das NAS versucht das Backup über ein Sparsefile anzulegen, während das Windowsprogramm Blocklevelzugriff braucht, da es eine VHD-Datei anlegt und bestimmte Dinge berechnet und direkt in der Datei anspringt. Da Windows keine Kenntnis vom Verhalten mit dem Sparsefile hat, kommt es zu falschen Berechnungen und damit scheitert die Sache früher oder später. Deshalb berichten viele von Problemen zu unterschiedlichen Gelegenheiten.

Als Lösung wurde genannt, man möchte in der smb.conf “strict allocate = yes” eintragen und den Samba-Server neu starten. Dadurch wird der für die Backupdateien benötigte Speicher immer komplett belegt.

Mal abgesehen, dass dieser Vorgang den Einsatz von Telnet erfordert, funktioniert diese Lösung aber auch nicht. Wie hier im Forum von QNAP diskutiert wird: http://forum.qnap.com/viewtopic.php?f=24&t=87109. Teilweise wird die Einstellung ignoriert oder geht nach einem weiteren Systemstart verloren oder sorgt für unnötige Auslastung des NAS. Offenbar ist es auch nicht nur ein Problem von QNAP sondern alle NAS-Hersteller kennen dieses Problem. Also Netgears ReadyNAS, FreeNAS, Synology usw. scheinen alle das Problem zu haben.

Was ist nun die Alternative? iSCSI

iSCSI ist etwas schwieriger einzurichten aber scheinbar momentan die einzig sinnvolle Lösung, solange das betreffende NAS iSCSI-Unterstützung mitbringt. Aber auch iSCSI birgt seine Gefahren: http://newyear2006.wordpress.com/2013/01/05/windows-server-2008-r2-bzw-sbs-2011-datensicherung-fehlercode-2155348061/

Sollte all das der Grund sein, warum MS nun die Sicherung in die CloudOS propagiert?

SSL/TLS Fehler in Powershell, bzw. wie man Zertifikatsprobleme unter Windows analysieren kann

4 Januar 2014

Beim Herumspielen mit Chocolatey, dazu ein anderes Mal mehr, gab es Probleme auf einem Windows XP-Rechner. Der Windows XP Rechner war für Chocolatey noch nicht vorbereitet, d. h. er hatte zwar .Net 1, 2 und 3.5 bereits aber noch kein .Net Framework 4. Powershell 2 war bereits installiert.

Ausgangslage
Der Aufruf von

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString(‘https://chocolatey.org/install.ps1&#8242;))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

für die Installation, führte zu folgender Fehlermeldung:

Exception calling "DownloadString" with "1" argument(s): "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."
At line:1 char:47
+ iex ((new-object net.webclient).DownloadString <<<< (‘https://chocolatey.org/
install.ps1′))
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

Der entscheidende Punkt ist oben rot markiert. Aber was macht man jetzt? Die Meldung ist leider doch zu allgemein.

Erster Versuch mehr Infos zum Fehler zu bekommen
Powershell kennt das $error Objekt. In diesem ist immer der letzte Fehler enthalten. Aber gleichzeitig sind bestimmte Randbedingungen und tiefergehende Infos zum Fehler abrufbar. Wichtig: Wenn man beim Rumspielen einen neuen Fehler verursacht, dann gehts schnell durcheinander und man untersucht nicht den eigentlichen Fehler, sondern einen nachfolgenden! Also geht man zuerst her und sichert den Fehler:

$myE = $error[0]

Damit kann nun nichts schiefgehen und mittels verschiedenen Abfragen kommt man dann irgendwann dazu:

((($myE).Exception).InnerException).Innerexception
The remote certificate is invalid according to the validation procedure.

Aha, wir haben also ein Zertifikatsproblem.

Prüfung mittels Browser
Aber welches Zertifikat macht nun die Probleme? Wie kann man dies überprüfen? Ein einfacher Versuch ist mittels Browser, in diesem gibt man einfach im aktuellen Fall https://chocolatey.org ein und schaut was passiert. Wer jetzt Chrome benutzt, der ist fein raus und bleibt verdutzt zurück, wer es aber mit dem Internet Explorer probiert, welcher den gleichen Weg einschlägt wie eben Powershell, bekommt diese Meldung:

Es besteht ein Problem mit dem Sicherheitszertifikat der Website.

Das Sicherheitszertifikat dieser Website wurde für eine andere Adresse der Website ausgestellt.

Die Sicherheitszertifikatprobleme deuten eventuell auf den Versuch hin, Sie auszutricksen bzw. Daten die Sie an den Server gesendet haben abzufangen.

Es wird empfohlen, dass Sie die Webseite schließen und nicht zu dieser Website wechseln.

Klicken Sie hier, um diese Webseite zu schließen.

Laden dieser Website fortsetzen (nicht empfohlen).

Weitere Informationen

Ja das kennen wir schon. Wenn man aber “Laden dieser Website fortsetzen (nicht empfohlen)” anklickt, bekommt man den bekannten roten Balken des IE mit dem Zertifikatsfehler. Dort kann man nun auf Zertifikatsfehler klicken und sich die Sache etwas genauer anschauen. Blöd nur das, dass es nicht offensichtlich ist, wo das Problem wieder genau liegt. Auf jeden Fall bekommt man raus, dass es sich in diesem Fall um Geotrust-Zertfikate handelt. Übrigens bekommt man diese Info auch von Chrome geliefert, wenn man auf das Schloss in der Adresszeile klickt und das Register Verbindung auswählt. Aber Hallo! Hier wird ein Go Daddy Zertifikat für chocolatey.org genannt! Ja was denn nun? GeoTrust oder Go Daddy? Des Rätsel Lösung nennt sich SNI und wird am Ende aufgelöst.

Tiefergehende Suche mittels Powershell
Wie kann man die Geschichte aber mittels Powershell besser in Griff bekommen? Da zu unterst immer irgendwo eine TCP-Verbindung aufgebaut werden muss, kann nur der direkte Aufruf über TCPClient etwas bringen.

Die einfachste Variante wäre nun:

$host = "chocolatey.org"
$port = 443
$conn = New-Object System.Net.Sockets.TcpClient ($host, $port)
$stream = New-Object System.Net.Security.SslStream($conn.GetStream())
$result=$stream.AuthenticateAsClient($host)
$conn.Close()

aber hier kommt nur wieder die Fehlermeldung wie oben bei der doppelten InnerException. Also was tun?

Der Konstruktor von SslStream kennt noch weitere Parameter. Unter anderem den RemoteCertificateValidationCallback Delegaten. http://msdn.microsoft.com/en-us/library/system.net.security.remotecertificatevalidationcallback(v=vs.110).aspx. Dieser wird üblicherweise benutzt, um bestimmte Fehlermeldungen in Verbindung mit Zertifikaten zu unterdrücken. Ab Powershell 2.0 ist dies ohne weiteres möglich, wie dieser Artikel hier schön beschreibt: http://www.nivot.org/blog/post/2009/07/18/PowerShell20RCWorking
WithNETCallbacksPart1Synchronous
. Der Callback kennt aber alle relevanten Informationen, so dass man diesen nun so nutzen kann:

$conn = New-Object System.Net.Sockets.TcpClient($host,$port)
$stream = New-Object System.Net.Security.SslStream($conn.GetStream(), $null, {
                    Write-Host "Sender: $($args[0])";
                    Write-Host "Certificate: $(($args[1]).gettype())";
                    Write-Host "CertificateChain: $($args[2])";
                    Write-Host "PolicyErrors: $($args[3])"; 
         })
$result = $stream.AuthenticateAsClient($host)
$conn.Close()

nun bekommt man als Ergebnis dies geliefert:

Sender: System.Net.Security.SslStream
Certificate: System.Security.Cryptography.X509Certificates.X509Certificate2
CertificateChain: System.Security.Cryptography.X509Certificates.X509Chain
PolicyErrors: RemoteCertificateNameMismatch

Also genau was auf MSDN als Parameter dokumentiert steht. Vor allem interessant ist nun die Aussage mit RemoteCertificateNameMismatch. Jetzt wird die Sache schon etwas klarer. Sollte chocolatey.org nicht im Zertifikat genannt sein?

Hier nun das Script welches die richtigen Infos ausgibt:

$conn = New-Object system.net.sockets.tcpclient($host, $port)
$stream = New-Object system.net.security.sslstream($conn.getstream(), $null, {
                    Write-Host $args[2].ChainElements[0].Certificate.Subject;
                    Write-Host "PolicyErrors: $($args[3])";
         })
$result = $stream.authenticateasclient("chocolatey.org")
$conn.Close()

Als Ausgabe erhält man:

CN=*.apphb.com, O=AppHarbor Inc, L=San Francisco, S=California, C=US, SERIALNUMBER=MyGg//QgdanmdPPqqfNR5JjsvbrKA/uJ
PolicyErrors: RemoteCertificateNameMismatch

Aha, nun wird es klarer. Wir wollen auf die Seite chocolatey.org bekommen aber ein Zertifikat vom Server für AppHarbor. Findet hier eine Attacke statt? Oh Gott, alle Schotten dicht!

Zusammenfassung
Ich wollte nur mal schnell Chocolatey installieren und bin dann wegen den Sicherheitsanforderungen von Chocolatey bei einer Attacke gelandet, wo mir irgendjemand falsche Zertifikate unterjubeln möchte. Oder ist doch alles ganz anders?

Aufklärung
Die Lösung des Dilemmas lautet SNI “Server Name Indication”. Ein schöner Artikel dazu findet man auf der deutschen Wikipedia unter http://de.wikipedia.org/wiki/Server_Name_Indication. Dort wird im Zusammenhang von SNI darauf hingewiesen, dass Windows XP kein Server Name Indication unterstützt. Warum ist dies wichtig? Weil Powershell mittels der Systembibliotheken von Windows XP seine HTTPS Verbindung aufbauen möchte und ebenso wie der IE8 Probleme bekommt. Hintergrund dafür ist, dass chocolatey.org bei HTTPS-Verbindungen auf SNI angewiesen ist, wie dieser Test zeigt: https://www.ssllabs.com/ssltest/analyze.html?d=chocolatey.org.

Dort ist dann zu lesen:

This site works only in browsers with SNI support.

Dies erklärt nun auch die unterschiedlichen Zertifikate. Denn IE8 auf Windows XP kann kein SNI, Chrome jedoch kann es, obwohl Windows XP zum Einsatz kommt. Der Grund dafür ist, dass Chrome seine eigene Crypto-Library mitbringt.

Beim Versuch also die Verbindung ohne SNI aufzubauen, landet man nicht auf dem gewünschten Server sondern bekommt ein allgemeineres Zertifikat des Hosters zurück. Dies erklärt nun den Punkt mit den unterschiedlichen Zertifikaten von GeoTrust und Go Daddy.

Man kann die Sache sehr schön nachverfolgen, wenn man Fiddler einsetzt. http://fiddler2.com/. Damit kann man, wenn der HTTPS-Mitschnitt aktiviert ist, sehr schön sehen, dass Powershell 2.0 diesen Aufruf generiert:

Version: 3.1 (TLS/1.0)

Extensions:
renegotiation_info 00
Ciphers:
[0004] SSL_RSA_WITH_RC4_128_MD5
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[0009] SSL_RSA_WITH_DES_SHA
[0064] TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
[0062] TLS_RSA_EXPORT1024_WITH_DES_SHA
[0003] SSL_RSA_EXPORT_WITH_RC4_40_MD5
[0006] SSL_RSA_EXPORT_WITH_RC2_40_MD5
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0012] SSL_DHE_DSS_WITH_DES_SHA
[0063] TLS_DHE_DSS_EXPORT1024_WITH_DES_SHA

Compression:
[00] NO_COMPRESSION

Während Chrome dies zustande bringt:

Version: 3.1 (TLS/1.0)

Extensions:
 server_name chocolatey.org
renegotiation_info 00
elliptic_curves secp256r1 [0x17], secp384r1 [0x18], secp521r1 [0x19]
ec_point_formats uncompressed [0x0]
SessionTicket TLS empty
NextProtocolNegotiation empty
ALPN  spdy/2; spdy/3; spdy/3.1; http/1.1;
channel_id empty
status_request 01 00 00 00 00
Ciphers:
[C02F] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[009E] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
[009C] TLS_RSA_WITH_AES_128_GCM_SHA256
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[0039] TLS_DHE_RSA_WITH_AES_256_SHA
[0035] TLS_RSA_AES_256_SHA
[C011] TLS_ECDHE_RSA_WITH_RC4_128_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
[002F] TLS_RSA_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA

Compression:
[00] NO_COMPRESSION

Der Extensions-Eintrag server_name chocolatey.org ist genau der Punkt, welcher beim Powershell-Aufruf fehlt und die Sache zum Scheitern bringt. Gleichwohl auch Chrome innerhalb von Fiddler Probleme mit dem Aufruf bekommt, denn Fiddler2 basiert auf .Net Framework 2.0 und damit ist der weitere Fortgang zum Scheitern verurteilt und man bekommt am Ende nicht das Go Daddy Zertifikat sondern wieder das falsche GeoTrust Zertifikat.

Übrigens geht genau dieser Artikel auf das aktuelle Problem ein und bestätigt nochmal alles: https://groups.google.com/forum/#!searchin/chocolatey/geotrust$20/chocolatey/r9EdhJdPjWM/FavaGm07VtoJ

Zu guter Letzt noch die Bestätigung, dass Powershell 4.0 unter Windows 8.1 problemlos damit umgehen kann:

A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Version: 3.1 (TLS/1.0)

Extensions:
renegotiation_info 00
 server_name chocolatey.org
elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
SessionTicket TLS empty
Ciphers:
[002F] TLS_RSA_AES_128_SHA
[0035] TLS_RSA_AES_256_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5

Compression:
[00] NO_COMPRESSION

Also alles halb so wild, wenn man weiß, wie es zusammenhängt!

Probleme Excel Dateien auf Windows zu öffnen mit Meldung Datei.XLSX konnte nicht gefunden werden.

4 Januar 2014

Beim Versuch eine Excel-Datei auf einem Netzlaufwerk zu öffnen gab es unter Windows Vista Probleme. Es erschien beim Doppelklick auf die Datei auf dem Serverlaufwerk folgende Meldung:

[Window Title]

N:\Eigene Dateien\Zeit\Zeit2014\TestExcel.xlsx

[Content]

"N:\Eigene Dateien\Zeit\Zeit2014\TestExcel.xlsx" konnte nicht gefunden werden. Stellen Sie sicher, dass Sie den Namen richtig eingegeben haben und wiederholen Sie den Vorgang.

[OK]

Eigentlich war der Zugriff seither problemlos möglich. Aber Netzlaufwerk impliziert Rechte und damit wurden zunächst die Benutzerrechte überprüft.

Doch der Benutzer hatte alle Rechte:

N:\Eigene Dateien\Zeit\Zeit2014>icacls TestExcel.xlsx

TestExcel.xlsx Jeder:(I)(RX,W)
DOMÄNE\Benutzer:(I)(F)
NT-AUTORITÄT\BATCH:(I)(M,DC)
NT-AUTORITÄT\INTERAKTIV:(I)(M,DC)
NT-AUTORITÄT\DIENST:(I)(M,DC)
NT-AUTORITÄT\SYSTEM:(I)(F)
VORDEFINIERT\Administratoren:(I)(F)

1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler aufgetreten.

Komisch. Dann der Versuch die Datei zu kopieren und zu löschen. Erwartungsgemäß funktionierte dies alles, nur das Öffnen war nicht möglich. Dann der Versuch mit einer Word-Datei, funktionierte perfekt. Dann der Versuch die Sache lokal in einem Temp-Verzeichnis zu testen. Aber immer noch dasselbe Problem.

Lösung
Spätestens jetzt war klar, dass es ein Excel-spezifisches Problem sein muss. Die Suche nach der Fehlermeldung brachte dann schließlich diesen KB-Artikel zum Vorschein: http://support.microsoft.com/kb/211494. Hier ist genau das Problem beschrieben und kann durch Abschalten bei Excel-Optionen->Erweitert->Allgemein->”Andere Anwendungen ignorieren, die Dynamischen Datenaustausch (Dynamic Data Exchange, DDE) verwenden” ausgeschaltet werden.

Der KB-Artikel auf deutsch, ist wie immer nicht auf dem aktuellen Stand, sondern ist zum Zeitpunkt dieses Artikel zuletzt am 4.12.2012 mit Version 5.0 aktualisiert worden. Geht man auf die englische Beschreibung http://support.microsoft.com/kb/211494/en dann wird dort auf einmal auch Excel 2013 noch genannt. Die Revision ist meilenweit von der deutschen weg: Article ID: 211494 – Last Review: October 15, 2013 – Revision: 16.0. Hier ist auch explizit Windows 8 genannt. Uaaahhh Microsoft, wie kann man nur so einen Schrott rauslassen!

Windows 8.1 – Apps bzw. moderne Anwendungen -Probleme lösen

24 Oktober 2013

Uns allen fehlt die Erfahrung mit dem Umgang von Apps bei Problemen, unter Windows 8 oder Windows 8.1. Wenn es um moderne Anwendungen geht, also Apps die man aus dem Microsoft App Store geladen hat.

Was macht man nun, wenn etwas nicht wie erwartet funktioniert? Wo kann man nachschauen, warum eine App nicht startet oder irgendwann ihren Dienst verweigert? Ein interessanter Blog-Eintrag ist dieser: http://blogs.technet.com/b/askperf/archive/2013/10/11/what-to-do-if-your-windows-8-modern-app-fails-to-start.aspx. Es werden einige wichtige Aspekte erläutert.

Hier noch die offizielle, allgemeinere Beschreibung was man tun kann: http://windows.microsoft.com/en-us/windows-8/what-troubleshoot-problems-app.

Auch taucht das Tool WSRESET.EXE auf, welches den Windows Store zurücksetzt, allerdings scheinbar auf Kosten der von Microsoft vorinstallierten Apps! Das Thema muss wohl noch genauer untersucht werden, da kaum offizielle Dokumentationen darüber existieren.

Internet Explorer 11 ist sehr langsam – Ups, wo ist der Kompatibilitätsmodus geblieben?

19 September 2013

Ha ha, mal wieder eine Meisterleistung der Pfeifen von MS. Der neue Internet Explorer ist so was von langsam, das ist unglaublich. OK, ich gebe es zu, nicht immer aber doch ab und an. Das brutale dabei ist, dass es sogar dem langsamsten Benutzer auffällt!

Wie äußert sich dies? Im selben Netzwerk mit identischer Hardware wird dieselbe Internetseite von Windows 7 mit IE 10 und mit Windows 8.1 und IE 11 angefahren. IE 10 zeigt die Seite schon vollständig an, da ist IE 11 noch am überlegen, überhaupt etwas anzuzeigen. Die Webseite ist auch bei der Bedienung gefühlt hakelig. Das Highlight ist aber der Druck, da dauert es eine halbe Ewigkeit, bis etwas ausgespuckt wird.

Zunächst dachte ich, es würde einfach an der Leitung und der angefahrenen Webseite liegen. Aber bei mehreren Versuchen und Vergleichen, musste ich dann feststellen, dass es am IE11 und nicht an der Internetseite liegen muss.

Jetzt muss man wissen, dass MS mal wieder einem in die Tasche lügt und behauptet mit IE11 wird alles schneller, hier zwei Beispiele: http://blogs.msdn.com/b/ie/archive/2013/09/18/ie11-release-preview-for-windows-7-30-faster-than-other-browsers-and-even-more-support-for-web-standards.aspx und http://blogs.msdn.com/b/ie/archive/2013/09/12/using-hardware-to-decode-and-load-jpg-images-up-to-45-faster-in-internet-explorer-11.aspx. Hört sich alles toll an. Wenn aber das tägliche Arbeiten mit Webseiten nicht mehr möglich ist, dann gehen die Optimierungen irgendwie in die falsche Richtung. OK, ich muss sagen, die Webseite hält sich nicht an die neuesten Standards aber wer macht das schon? Der Punkt Standards brachte mich dann auch zu Lösung.

Die Lösung ist denkbar einfach. Man aktiviert einfach den Kompatibilitätsmodus. Früher war dieser direkt in der URL-Eingabezeile durch ein kleines Symbol sichtbar, bei IE11 ist dies aber nicht mehr der Fall, statt dessen gibt es einen Menüpunkt dafür. Dieser nennt sich “Einstellungen der Kompatibilitätsansicht”, dort kann man dann die betreffende URL der langsamen Seiten hinzufügen. Danach flutschte die Seite wieder.

Eine weitere, für mich allerdings zweifelhafte Lösung, wäre das Ändern des Agent-String wie von einem MVP hier vorgeschlagen: http://answers.microsoft.com/en-us/ie/forum/ie11_pr-windows8_1_pr/problem-with-opening-some-websites-in-ie-11-in/242c2d8e-242d-49c2-8aa5-759c533ba6ae

Windows 8 und Windows 8.1 machen Probleme bei Schachtanwahl beim Drucken

17 September 2013

Mit Einführung von Windows 8 hat Microsoft eine neuere Version vom Treibermodell für Drucker eingeführt, die sogenannte Version 4. Hier wird das neue Modell im Vergleich zur alten Version beschrieben: http://technet.microsoft.com/de-de/library/jj134171.aspx.

Wenn  man die von Microsoft gelieferten Standardtreiber für seine Drucker benutzt, läuft man Gefahr, dass es Probleme bei der Schachtanwahl beim Drucken gibt. Konkret bedeutet es, dass bei einem Druckjob ein Kommando für die Schachtanwahl einer anderen Kassette ignoriert wird. Das perfide an der Sache ist nun aber, dass wenn man beim Drucken der Windowstestseite einen Schacht davor explizit auswählt, dann funktioniert die Schachtwahl anstandslos!

Wann immer aber ein Schachtwechsel während des Druckjobs erfolgt, wird dieser Wechsel ignoriert, lediglich die erste Schachtwahl wird an den Drucker korrekt übertragen. Das Problem trat konkret bei einem HP Laserjet 2430 DTN auf, aber aufgrund des Abstraktionsgrad der Treiber, muss man davon ausgehen, dass mehrere HP Laserjet Modelle davon betroffen sind. Wenn es blöd läuft, alle auf PCL6 basierende Treiber.

Die Lösung ist zunächst die Verwendung von HP-Treibern, diese sind momentan noch V3-Treiber und arbeiten korrekt.

Wenn man herausfinden möchte, welcher Druckertreiber auf welcher Basis funktioniert, muss es etwas komplizierter ermitteln: Man ruft Geräte und Drucker in der Systemsteuerung auf, klickt dort einen Drucker an, z. B. “Microsoft XPS Document Writer”. Nun erscheint in der oberen Leiste Druckerservereigenschaften. Klickt man diesen Punkt an, erscheint ein Dialog in dem man nun das Register Treiber anklickt. Dort steht nun bei Typ entweder Typ 3 oder Typ 4 für die Version.

Wenn man mittels Powershell erfahren möchte, welcher Treiber welche Version verwendet kann diesen Befehl verwenden:

Get-PrinterDriver

In der Spalte MajorVersion steht dann 3 oder 4 für die Version bzw. den Treibertyp.


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.