Archive for the ‘Problemlöser’ Category

Wenn Maus und Tastatur an einem Windows Rechner nicht mehr reagieren

14 Dezember 2014

Ein Kunde hatte ein Problem mit seinem Windows 7 Rechner. Das interessante daran war, dass Tastatur und Maus nicht mehr funktionierten, wenn Windows hochgefahren war. Er hatte die Passworteingabe beim Hochfahren deaktiviert, so dass der Rechner immer bis zum Desktop bootete. So konnte man schon beobachten, dass alles sauber geladen wurde nur am Ende war keinerlei Maus und Tastatureingabe möglich. Der Mauszeiger konnte nicht einmal bewegt werden.

Der Rechner konnte problemlos durch drücken des Ausschaltknopf sauber heruntergefahren werden. Die Maus und Tastatur konnten an anderen Ports eingesteckt werden und es erschien die Meldung, dass Treiber installiert werden und dass das Gerät nun benutzt werden kann. Jedoch war dies nie möglich.

Bei weiteren Versuchen stellte es sich heraus, dass auch eine PS/2-Tastatur nicht funktionierte. Ein generelles Hardwareproblem konnte aber ausgeschlossen werden, da Maus und Tastatur problemlos unter WindowsPE oder im BIOS funktionierten. Ein weiterer Aspekt war, dass Multimediatasten wie E-Mail, Calculator usw. einer Multimediatastatur auch funktionierten.

Ein Starten des Rechners im abgesicherten Modus brachte leider auch nichts.

Also alles neu installieren? Nein.

Zwei Dinge helfen:
Die Verwendung der erweiterten Startoptionen und Aufruf von Computer reparieren. http://windows.microsoft.com/de-de/windows/advanced-startup-options-including-safe-mode#1TC=windows-7. Hier kann man die Systemwiederherstellung aufrufen, damit ein früherer Zustand aktiviert werden kann, der funktionierte – soweit vorhanden.

Die zweite Lösung wäre das entfernen von Kaspersky Maus und Tastaturtreibern. Dazu musste man nur in der Registrierung unter Upperfilters nach klkbdflt und klmouflt suchen und diese entfernen. Detailliert hier beschrieben: http://support.kaspersky.com/general/products/10663#block7. Diese Lösung funktionierte, weil der Kunde davor versucht hatte Kaspersky zu installieren und dabei scheinbar etwas schiefgegangen war. Hat man die Kaspersky-Treiber entfernt, stehen nur noch kbdclass und mouclass in der Registrierung. Übrigens muss man nicht zwingend die Kaspersky Rescue Disk verwenden, sondern kann auch mit einem WinPE oder Windows Bootmedium booten und die Registrierungseinträge darüber ändern.

Fehlermeldung von Windows Fax und Scan wegen fehlendem Faxkonto bei Druck über Faxserver

26 November 2014

Bekommt man an einem Windows Client beim Druck über einen Faxserver folgende Fehlermeldung an den Latz geknallt:

—————————

Windows-Fax und -Scan

—————————

Sie müssen erst ein Faxkonto erstellen, um Faxe mit dem ausgewählten Drucker senden zu können. Suchen Sie nach "Computer zum Senden und Empfangen von Faxen einrichten" in Hilfe und Support", um weitere Informationen zu erhalten.

—————————

OK  

—————————

 

So kann man sich behelfen, indem man zunächst bei Windows Fax und Scan im Menü unter Extras->Faxkonten den bestehenden Eintrag entfernt. Anschließend das Programm zumachen und noch bei Drucker und Faxgeräten den betreffenden Druckertreiber, der fürs Faxen über den Server eingerichtet war, über “Gerät entfernen” loswerden.

 

Nun wieder über Windows Fax und Scan über das Extra-Menü Faxkonten aufrufen, Hinzufügen anklicken und “Verbindung mit einem Faxserver im Netzwerk herstellen” auswählen. Dann den Servernamen eingeben usw. Danach sollte es ohne obige Fehlermeldung klappen.

SBS2003 Server machte nach Internetproviderumstellung Probleme mit DNS-Namensauflösungsanfragen

2 August 2014

Nachdem bei einem Kunden der Internetprovider gewechselt wurde, kam es zu massiven Problemen bei den Clientrechnern. Bei Zugriffen, vor allem auf kompliziertere oder mittels HTTPS verschlüsselten Seiten wie bahn.de, ebay.de, mobile.de usw. gab es teilweise ewige Verzögerungen und am Ende sogar Timeouts, so dass die Seiten nicht korrekt dargestellt wurden.

Der SBS hat bekanntlich noch zwei Netzwerkkarten. Davon wird eine für den lokalen Netzwerkverkehr verwendet und die zweite ist das Gateway nach außen. Der neue Internetprovider hatte ein Gerät installiert, wo ein anderer IP-Adressbereich hinterlegt war. Demzufolge musste beim SBS in den Netzwerkkarteneinstellungen die neue IP-Adresse für die Kommunikation mit dem externen Router hinterlegt werden. Damit fingen die Probleme an.

Am SBS-Server war ein gewohnt schneller Zugriff auf alle Seiten möglich. Allerdings war auf den Clientrechnern eben obige Aussetzer zu beobachten. Auch ein Test mit Googles-DNS-Server-Adresse 8.8.8.8 auf dem Client brachte die übliche Geschwindigkeit. Was tun? Zunächst mittels Ping und NSlookUp versucht der Sache auf die schliche zu kommen. Nach vielen Tests und einigem hin- und her hatte es sich herausgestellt, dass am SBS noch ein DNS-Forward eingestellt werden sollte.

Mittels

dnscmd /info

kann man verschiedene Infos zum DNS abfragen:


  Aging Configuration:
        ScavengingInterval           = 0
        DefaultAgingState            = 0
        DefaultRefreshInterval       = 168
        DefaultNoRefreshInterval     = 168
  ServerAddresses:
Addr Count = 2
                Addr[0] => 192.168.60.1
                Addr[1] => 192.168.10.2
  ListenAddresses:
Addr Count = 1
                Addr[0] => 192.168.60.1
  Forwarders:
Addr Count = 1
                Addr[0] => 192.168.1.1
        forward timeout  = 5
        slave            = 0
Command completed successfully.

Hier sieht man sehr schön, dass zwar die IP-Adresse der zweiten Netzwerkkarte Addr[1] passend zum neuen Router gesetzt wurde aber die Adresse Addr[0] des Forwarders noch auf den alten IP-Bereich eingestellt ist. Wichtig dabei ist nun auch der Timeout=5, was 5 Sekunden entspricht.

Wenn man es weiß, ist nun die Sache schnell erledigt:

dnscmd . /ResetForwarders 192.168.10.1 /TimeOut 5 /Slave

Damit wurde Addr[0] des Forwarders auf die korrekte Adresse.

Interessant an der Geschichte ist vor allem, dass Seiten mit Subdomains massive Probleme bekamen. Ist irgendwie logisch denn für jede Subdomainanfrage kam der Timeout mit 5 Sekunden zu tragen.

So führte ein einfacher Aufruf von ebay.de und das klicken auf Einloggen zu zig Domainabfragen, hier einige davon:

www.ebay.de
secureir.ebaystatic.com
ir.ebaystatic.com
securepics.ebaystatic.com
srx.de.ebayrtm.com
cors.api.paypal.com
thumbs2.ebaystatic.com
thumbs3.ebaystatic.com
thumbs4.ebaystatic.com
p.ebaystatic.com
www.paypalobjects.com
b.stats.ebay.com
314797b0qxk.stats.ebay.com
signin.ebay.de
phx.stats.paypal.com
src.ebay-us.com
sofe.ebay.de
rover.ebay.de
rtm.ebaystatic.com
pics.ebaystatic.com
secureir.ebaystatic.com
pages.ebay.de
i.ebayimg.com

Was für eine Auflistung! Über 20 DNS-Abfragen werden benötigt um die Start- und dann die Loginseite aufzurufen. Pech, wenn man sowas unterwegs in einem Edge- oder noch besser GPRS-Handynetz macht, wo jede Anfrage ca. 200 Millisekunden und mehr dauert…

Ereignisanzeige Protokollnamen für Powershell übersetzen

28 Juli 2014

Durch den vorhergehenden Blogeintrag http://newyear2006.wordpress.com/2014/07/28/windows-store-konnte-die-computerlizenzen-nicht-synchronisieren-ergebniscode-0x80070490/ bin ich wieder mal über ein Problem gestolpert, dem ich schon häufiger begegnet bin, deshalb dieses Mal fürs löchrige Gehirn etwas ausführlicher.

Es ging um ein Problem, welches in der Ereignisanzeige mit dem Protokollnamen "Microsoft-Windows-Store-Licensing/Admin" erfasst ist. Möchte man nun diesen Event per Powershell ermitteln, passiert folgendes:

PS>Get-WinEvent -LogName Microsoft-Windows-Store-Licensing/Admin
Get-WinEvent : Auf dem Computer "localhost" wurde kein Ereignisprotokoll gefunden, das
"Microsoft-Windows-Store-Licensing/Admin" entspricht.
In Zeile:1 Zeichen:1
+ Get-WinEvent -LogName Microsoft-Windows-Store-Licensing/Admin
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Microsoft-Windows-Store-Licensing/Admin:String) [Get-WinEvent], Excepti
   on
    + FullyQualifiedErrorId : NoMatchingLogsFound,Microsoft.PowerShell.Commands.GetWinEventCommand

Gut, vielleicht kann man es auch mit Anführungsstrichen probieren? Leider bringt dies auch nichts. Microsoft-Windows-Store-Licensing steht jetzt auch nicht im Verdacht in der falschen Sprache angegeben zu sein oder?

Nächster Versuch, man könnte ja alles mit Namen *Licen* auflisten lassen:

PS> Get-WinEvent -ListProvider *licen*

Name     : Microsoft-Windows-Kernel-LicensingSqm
LogLinks : {}
Opcodes  : {}
Tasks    : {}

Name     : Microsoft-WS-Licensing
LogLinks : {Microsoft-WS-Licensing/Diagnostic, Microsoft-WS-Licensing/Debug, Microsoft-WS-Licensing/Admin}
Opcodes  : {win:Start, win:Stop}
Tasks    : {Service_Init, Service_Stop, Service_Init_LicenseStore, Service_Init_HwidCollect…}

Name     : Microsoft-Windows-Kernel-Licensing-StartServiceTrigger
LogLinks : {}
Opcodes  : {}
Tasks    : {}

Sieht auch nicht sehr ergiebig aus. Wobei Microsoft-WS-Licensing geht ja in die Richtung, wenn WS für Windows Store stehen würde:

PS > (Get-WinEvent -ListProvider *licen*).Loglinks

LogName                          IsImported DisplayNam
——-                           ———- ———
Microsoft-WS-Licensing/Diagnostic      False
Microsoft-WS-Licensing/Debug           False
Microsoft-WS-Licensing/Admin           False

OK, es ist kein Displayname eingetragen, also wird es das auch nicht sein. Oder vielleicht doch? Ich bin ja immer noch der Meinung, WS steht für Windows Store. Da Powershell teilweise immer etwas Daten vor einem verheimlicht, lasse ich mir alle Daten zu einem Objekt ausgeben:

Get-WinEvent -ListProvider *licen*| fl *

Siehe da, hier gibt es auch ein Displayname Feld. Also mal dieses ausgeben lassen:

PS> (Get-WinEvent -ListProvider *licen*).displayname
Microsoft-Windows-Store-Licensing
Microsoft-Windows-LicensingStartServiceTrigger

Ah da isses ja. Der gesuchte Microsoft-Windows-Store-Licensing-Protokollname. Deutlicher wird es damit:

PS C:\Windows\system32> (Get-WinEvent -ListProvider *licen*)| select displayname, providername| fl

DisplayName  :
ProviderName : Microsoft-Windows-Kernel-LicensingSqm

DisplayName  : Microsoft-Windows-Store-Licensing
ProviderName : Microsoft-WS-Licensing

DisplayName  : Microsoft-Windows-LicensingStartServiceTrigger
ProviderName : Microsoft-Windows-Kernel-Licensing-StartServiceTrigger

Es geht halt nichts über eine ordentliche Übersetzung! Übrigens wäre es auch noch einfacher gegangen. Einmal über die GUI-Methode, indem man beim betreffenden Protokolleintrag sich die Details anzeigen lässt und dann System erweitert. Dort taucht dann unter Provider ebenso wieder “Microsoft-WS-Licensing” auf.

Man kann nun also mittels

Get-WinEvent -LogName Microsoft-WS-Licensing/Admin -MaxEvents 10

eine schöne Auflistung der Fehler erhalten.

Windows Store konnte die Computerlizenzen nicht synchronisieren. Ergebniscode: 0x80070490

28 Juli 2014

Weil es so schön ist und auch diese Meldung einem regelmäßig in den Eventlogs der Windows 8.1-Rechner entgegenfliegt:

Windows Store konnte die Computerlizenzen nicht synchronisieren. Ergebniscode: 0x80070490

Eingeführt mit dem Update auf Windows 8.1 erscheint diese Meldung jeden Tag einmal. Die Ereginis-ID lautet 512 und die Quelle ist Store-Licensing.

Klickt man den Onlinehilfelink an, erscheint:

image

Man beachte 9871 von 39506 Leute fanden diese Seite gut!

Microsoft hat im Zuge der Nokiaübernahme gerade 18000 Leute entlassen, davon sind auch mehrere tausend Microsoftmitarbeiter betroffen, hier einer davon: https://www.youtube.com/watch?v=lRV6PXB6QLk. Der Mann im Video stellt sich die berechtige Frage, wie man Windows am Laufen halten möchte? Die letzten Jahre mangelt es bereits an Dokumentation und vor allem an Supportdokumenten und dann hauen die auch noch zig tausend Leute raus. Die hätten besser die Leute behalten und zu 12 Monaten Zwangsdokumentation schreiben und Bugfixing verdonnern sollen.

Aber zurück zum Thema. Über diesen Thread bin ich an den passenden Eintrag gekommen: http://www.eightforums.com/general-support/50300-windows-store-failed-sync-machine-licenses-0x80070490.html. Wie so oft gibt es ja keinen offiziellen Knowledge Base Eintrag dazu. Wozu fehlende Dokumentation und unnütze Fehler  führen können, zeigt sich an diesem Thread: http://answers.microsoft.com/en-us/windows/forum/windows8_1-windows_store/w81-update-1-windows-store-failed-to-sync-machine/2ea6a4b8-c50c-444f-a4ef-f7ee7705f1ae.

Also nun mittels Powershell mal wieder rumgebastelt und die These überprüft. Wenn man diesen Befehl eingibt:

Get-ScheduledTask WSRefreshBannedAppsListTask | Start-ScheduledTask

Dann wird der betreffende Task erneut gestartet. In diesem Fall wird wieder der Eventeintrag generiert, diesen kann man nun mittels

Get-WinEvent -LogName "Microsoft-WS-Licensing/Admin" -MaxEvents 1| select id,timecreated,message | fl

abfragen und erhält:

Id          : 512
TimeCreated : 28.07.2014 16:33:36
Message     : Windows Store konnte die Computerlizenzen nicht synchronisieren. Ergebniscode: 0x80070490

Um also die nervige Protokollierung der Fehlereinträge aus den Eventlogs weg zu bekommen, ruft man

Get-ScheduledTask WSRefreshBannedAppsListTask | Disable-ScheduledTask

auf. Damit wird der Dienst deaktiviert.

Da leider keine Dokumentation verfügbar ist, was die Aufgabe des Tasks genau ist, ist die Frage, ob man sich durch das Deaktivieren irgendwelche Negativeffekte einhandelt. Die Zeit wird es zeigen…

Hyper-V-VMMS Ereignisanzeige Fehler 19510 Problem mit Installationsdatenträger für die Integrationsdienste und Fehler 0x80070020

28 Juli 2014

Wer einen Hyper-V Server am Laufen hat, dem könnte diese wie immer vielsagende Fehlermeldung über den Weg laufen:


Das Image des Installationsdatenträgers für die Integrationsdienste konnte nicht aktualisiert werden: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. (0x80070020).

Alles klar? Ich klicke auf Onlinehilfe und bekomme:

—————————
Ereignisanzeige
—————————
Die Onlinehilfe des Ereignisprotokolls kann nicht angezeigt werden, da der Standardbrowser nicht gestartet werden konnte.Klasse nicht registriert
—————————
OK  
—————————

Wird halt immer besser! Saftladen.

Powershell angeworfen und dieses angeschaut, man hat ja einen Riecher:

(get-vm).dvddrives

und dies bekommen:

VMName       Path
——       —-
AndroidX86   C:\Users\XXX\Downloads\android-x86-4.3-20130725.iso
AndroidX86-2 C:\Users\XXX\Downloads\android-x86-4.3-20130725.iso
Test
UbuntuTest
VistaTest    C:\WINDOWS\system32\vmguest.iso
W2K12R2Core

OK, ausgehend von der obigen Meldung mit den Integrationsdiensten macht es Sinn. Denn scheinbar will der Rechner die VMGUEST.ISO aktualisieren, kann es aber nicht, weil diese gerade bei einer VM in Benutzung ist. Dieser Fehler dürfte in Client-Hyper-V Umgebungen sicherlich häufiger auftreten.

DCOM Fehlermeldungen 10010 in Ereignisanzeige mit BF6C1E47-86EC-4194-9CE5-13C15DCB2001 und 1B1F472E-3221-4826-97DB-2C2324D389AE bei Windows 8.1

28 Juli 2014

Die Anfänger von Microsoft haben mal wieder zugeschlagen und beglücken die Welt mit sinnlosen Fehlermeldungen. Wenn man in der Ereignisanzeige eines Windows 8.1 Rechners diese beiden Meldungen findet:

Der Server "{1B1F472E-3221-4826-97DB-2C2324D389AE}" konnte innerhalb des angegebenen Zeitabschnitts mit DCOM nicht registriert werden.

Der Server "{BF6C1E47-86EC-4194-9CE5-13C15DCB2001}" konnte innerhalb des angegebenen Zeitabschnitts mit DCOM nicht registriert werden.

Dann hat dies mit einem Problem mit Skydrive bzw. Onedrive zu tun. Flankiert werden die Meldungen von der Ereignis-ID 10010 mit der Quelle DistributedCOM.

Da Microsoft erwiesenermaßen keine Ahnung von COM und von DCOM hat, werden wahrscheinlich aktuell viele Windows 8.1 Rechner mit dieser Fehlermeldung beglückt. Kommt mir gerade die Frage in den Sinn: Wer hat COM und DCOM nur erfunden? Mmhh.

Aufgrund dieses Threads http://answers.microsoft.com/en-us/windows/forum/windows8_1-performance/event-error-10010/69540cfb-a90c-47e1-b8a5-0b51eb0302d5 war schnell klar, dass es sich um ein Problem mit Skydrive handelt. Die Härte sind mal wieder Aussagen eines MVPs, man solle die Fehler einfach ignorieren. Gehts noch? OK, wenn schon ignorieren, dann am besten dadurch, dass man MS Produkte ignoriert. Das wäre die passendere Aussage gewesen.

Man kann zwar nun in der Aufgabenplanung hergehen und den “Idle Sync Maintenance Task” und den “Routine Maintenance Task” deaktivieren aber der Beweis, dass diese beiden Aufgaben tatsächlich etwas damit zu tun haben steht noch aus. Denn bei den Aktionen des jeweiligen Tasks ist jeweils nur ein “Benutzerdefinierter Handler” hinterlegt. Sehr aussagekräftig. Allerdings deutet auch der Hinweis bei “Ergebnis der letzten Ausführung” mit der Meldung “Starten des Servers fehlgeschlagen (0x80080005)” auf ein Problem hin. Hier eine kleine Abhandlung zum Fehler 0x80080005: http://blogs.msdn.com/b/adioltean/archive/2005/06/24/432519.aspx.

Aber zum Glück gibt es Powershell. Um die Sache etwas zu verdeutlichen ein kleines Powershell-Skript:

$t=Get-ScheduledTask -TaskPath \microsoft\windows\skydrive\
$t.Actions
$t.actions | select ClassId, Data

Wichtig ist der \ am Ende bei Skydrive! Sonst gibts einen Fehler:

Get-ScheduledTask : Es wurden keine MSFT_ScheduledTask-Objekte gefunden, bei denen die TaskPath-Eigenschaft gleich "\microsoft\windows\skydrive" ist. Überprüfen Sie den Wert der
Eigenschaft, und versuchen Sie es erneut…

Als Ausgabe erhält man:

ClassId                                Data
——-                                —-
{BF6C1E47-86EC-4194-9CE5-13C15DCB2001} IdleSyncMaintenance
{1B1F472E-3221-4826-97DB-2C2324D389AE} RoutineMaintenance

Dies sind genau die oben aufgeführten ClassIDs bei den Fehlermeldungen aus der Ereignisanzeige.

Um diese nun also zu deaktiveren, führt man als Admin noch dies aus:

$t | Disable-ScheduledTask

OK, nun ist man einen Schritt weiter aber wie lange? Funktioniert nun Onedrive nicht mehr? Abwarten und beobachten…

Bei Powershell SSL/TLS-Zertifikate-Prüfung einfach ignorieren

26 Juli 2014

Da alle Welt mittlerweile nach SSL/TLS-Transportverschlüsselung schreit, um die gröbsten Manipulationsmöglichkeiten während einer Datenübertragung, auszuschließen, bekommt man ein Problem, wenn man mal aus der Hüfte etwas ausprobieren möchte.

Aktueller Fall: Ein Web-Dienst soll kurz abgefragt werden um zu sehen, wie er reagiert. Aus Sicherheitsgründen ist dieser Dienst aber nur per HTTPS verfügbar, was zu folgendem Problem führt:

PS> Invoke-WebRequest -Uri "https://192.168.20.77:8802/cgi-bin/gadgetapi?cmd=Login&gsUser=14&gsPass=0815"
Invoke-WebRequest : Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten SSL/TLS-Kanal konnte keine Vertrauensstellung hergestellt werden..
In Zeile:1 Zeichen:1
+ Invoke-WebRequest -Uri "https://192.168.20.77:8802/cgi-bin/gadgetapi?cmd=Login&g
+ …~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
 

Eine simple und schnelle Lösung ist das Ausführen dieses Befehls:

add-type @"
    using System.Net;
    using System.Security.Cryptography.X509Certificates;
    public class TrustAllCertsPolicy : ICertificatePolicy {
        public bool CheckValidationResult(
            ServicePoint srvPoint, X509Certificate certificate,
            WebRequest request, int certificateProblem) {
            return true;
        }
    }
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

Danach ist der angefragte Server zufrieden und liefert das gewünschte Ergebnis:

PS> Invoke-WebRequest -Uri "https://192.168.20.77:8802/cgi-bin/gadgetapi?cmd=Login&gsUser=14&gsPass=0815"
Invoke-WebRequest : Der Remoteserver hat einen Fehler zurückgegeben: (403) Unzulässig.
In Zeile:1 Zeichen:1
+ Invoke-WebRequest -Uri "https://192.168.20.77:8802/cgi-bin/gadgetapi?cmd=Login&g
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
 

OK, 403 ist nicht optimal aber es ging nur darum einen korrekten HTTP-Statuscode zu bekommen!

Weitere Infos zu Powershell und SSL/TLS-Zertifikate und wie man bei Problemen weitere Infos erhält, findet man hier: http://newyear2006.wordpress.com/2014/01/04/ssltls-fehler-in-powershell-bzw-wie-man-zertifikatsprobleme-unter-windows-analysieren-kann/

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 0x00000006

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 0x00000006).

 

[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/


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.