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

Windows 8 Autostart Ordner – ja wo haben sie denn den versteckt?

9 Juli 2014

Da nun mittlerweile absehbar ist, dass es mit dem Startmenü bei Windows 8 nicht so schnell was wird, hier ein Tipp, wie man möglichst schnell zum Autostartordner kommt.

http://blogs.msdn.com/b/jasone/archive/2012/08/19/windows-8-where-did-the-startup-folder-go.aspx beschreibt die Funktion mittels:

shell:startup

nur als alter Commandliner muss man

start shell:startup

aufrufen. Wichtig, wenn man den allgemeinen Autostartordner möchte, funkt es so:

start "" "shell:common startup"

Wenn wir schon bei den kleinen Helferlein sind, mittels

control printers

öffnet sich der “Geräte und Drucker”-Ordner. Und

control update

öffnet die Windows Updates. Braucht man mehr bei der Einrichtung eines Rechners?

Übrigens die Befehle funktionieren auch bei Windows 7. Weitere Kürzel findet man hier: http://newyear2006.wordpress.com/2008/02/08/direktstartprogramme-unter-windows-vista-und-windows-xp/

Teamviewer hat seinen Zenit überschritten

5 Juli 2014

Schon längere Zeit ärgere ich mich über den Teamviewer. Es sind immer wieder Kleinigkeiten aber irgendwann wird es halt zu viel. Nachdem nun auch bekannt wurde, dass Teamviewer gar kein kleines nettes GmbHchen im beschaulichen Schwabenland mehr ist, sondern schon seit Jahren Teil eines Konzerns, kommen immer mehr Teile zusammen um Tschüss zu sagen. Aber der Reihe nach.

Der Anfang
Früher war alles gut. Kunde hatte Probleme, Teamviewer angeworfen, ID und Kennwort fertig. Es geht sogar noch einfacher, wenn man die IDs in der Cloud speichert. Das war am Anfang eine Offenbarung, wenn man davor mit pcAnywhere noch Firewalls manuell aufbohren musste, mit Kunden, die eh keinen Plan haben. Zumal man beliebig viele Kunden ohne Clientgebühren fernwarten konnte. Also nochmal ein Plus gegenüber viele andere damaliger Lösungen.

Eine zeit lang hätte sogar Microsoft im Bereich Remotesupport aktiv werden können mittels Remote Assistance und IPv6 mittels Teredo aber die sind ja blind.

Ein klarer Vorteil von Teamviewer ist auch die Plattformunabhängigkeit da Module für Windows, Mac OS X und Linux zur Verfügung stehen. Noch ein Pluspunkt war einen Neustart initiieren zu können und danach die Fernwartung fortsetzen zu können.

Technische Probleme häufen sich
Obwohl der Teamviewer weitgehend zuverlässig seine Arbeit macht, gab es doch immer wieder das eine oder andere Problem. Aber eigentlich alles Probleme die sich auf lange Sicht behoben haben, indem man neuere Versionen einsetzte.

Dennoch gibt es bestimmte Dinge, die einfach nie angegangen werden. Z. B. kann man eine Sitzung aufzeichnen und später anschauen, allerdings ist das Benutzerinterface dermaßen umständlich, dass es bei größeren Aufzeichnungen extrem mühsam ist, die gesuchte Stelle zu finden. Man kann zwar die Sitzung in eine übliche Videodatei mittels installierter Codes konvertieren lassen aber der Vorgang dauert schon so lange, dass man sich gleich mit den vorhandenen Mitteln seine Zeit vergeuden kann. Es gäbe so viele tolle Möglichkeiten, wenn der Videostream in einem Standardformat gespeichert würde.

Aufgrund des Erfolgs von Teamviewer ist er wahrscheinlich in Deutschland mit am verbreitetsten. Vor allem im KMU-Bereich. Soweit so gut. Dumm nur, wenn viele Hardwarebetreuer oder Kunden den Teamviewer in Vollversion auf Privatbasis installieren und dieser ständig im Hintergrund läuft. Das Problem dabei ist, dass viele unbedarfte Leute nicht wissen, was ein Systray bzw. Benachrichtigungsbereich ist. Dies führt zum Problem, dass wenn man schnell eine Fernwartung machen möchte und die Kunden den Quicksupport starten, dass es dann zu komischen, vor allem auch noch wechselnden Fehlermeldungen kommt. So wurde früher eine Proxy-Fehlermeldung angezeigt, wenn eine Instanz bereits im Hintergrund lief: http://newyear2006.wordpress.com/2011/05/25/teamviewer-meldet-keine-verbindung-zum-masterserver-oder-proxy-fehlermeldung/. Bei älteren Quicksupport Modulen bekommt man den Hinweis eine andere Instanz läuft bereits. Na Prima. Erst wenn man in der neuesten Fassung Teamviewer 9 und ein aktuelles Quicksupportmodul hat, bekommt man einen Hinweis:

Eine andere Instanz von TeamViewer läuft bereits. Bitte schließen Sie diese Instanz bevor Sie Teamviewer erneut starten.

Aktiven Teamviewer anzeigen   |   OK

Allerdings fängt damit kein normal sterblicher etwas an. Zumal, wenn man “Aktiven Teamviewer anzeigen” anklickt und dann die Instanz durch Schließen des Fenster zumacht, in den meisten Fällen, also in der Standardeinstellung die Instanz im Hintergrund weiterläuft. Nicht gerade logisch, wenn man davor eine Meldung angezeigt bekommt, die einem suggeriert man könnte die Instanz anzeigen lassen und dann schließen.

Nächster Fall, der im Prinzip mit der gerade geschilderten Problematik zu tun hat. Hat man eine Instanz des vollen Teamviewers im Hintergrund laufen und schafft es der Kunde, diese zu beenden, dann läuft immer noch ein Teamviewer Dienst im Hintergrund! D. h. es verschwindet das Symbol aus dem Benachrichtigungsbereich und die zugehöriger EXE wird beendet, aber der zugehörige Windows Service läuft weiter. Aber genau dieser Dienst führt dazu, dass wenn ein Quicksupportmodul aufgerufen wird, dass danach ein kontrollierter Neustart nicht mehr möglich ist. Einer der Vorteile von Teamviewer war immer einen Neustart des Remoterechners zu initialisieren und nach dem Neustart automatisch die Sitzung fortführen zu können. Aber dies ist nun aktuell nicht mehr möglich, wenn diese Meldung erscheint:

"Die gewünschte Aktion ist nur möglich, wenn Sie die auf diesem Computer installierte Version von Teamviewer verwenden oder keine andere Version von Teamviewer installiert ist."

Wenn man Teamviewer schon ein paar Jahre einsetzt und vor allem aktuell, durch den Umstieg von Windows XP auf neuere Systeme, sammeln sich extrem viele Kunden IDs. Für Teamviewer mag es ein toller Marketingerfolg sein von zig hundert Millionen betreuter Rechner zu reden. Die IDs sind zweifelsohne alle einmal erzeugt worden aber wie viele von denen werden aktiv benutzt? Genau dort taucht wieder ein Problem auf. Durch die vielen IDs durch Systemumstellungen sammeln sich hunderte von IDs und machen die Liste der Offlinekontakte zur Qual. Aus irgendwelchen unsinnigen Gründen wird auch noch die Liste der Offlinekandidaten ständig aufgeklappt, wobei dies gar nicht gewünscht ist.

Übrigens IPv6 wird auch nicht unterstützt, wahrscheinlich sogar bewusst nicht, da man sonst evtl. ohne den zentralen Teamviewerserver auskommen könnte.

Aber all diese Probleme werden von Teamviewer nie dokumentiert. Auch die Versionshistorie erstreckt sich auf ein Minimum an Information. Der Support von Teamviewer ist schlecht erreichen und hat gar kein Interesse Probleme anzugehen. Beschwerden werden mit E-Mailtickets meistens ausgesessen.

Das Highlight war dann im April 2014, als weltweit die Teamviewer Server ausfielen: http://www.heise.de/newsticker/meldung/Fernwartungstool-Teamviewer-gestoert-2160262.html. Wenn man in bestimmten Dingen von solch einem Dienst abhängig ist, dann hängt vieles davon ab, wie auf solch eine Panne reagiert wird. Aber es gab keine offizielle Verlautbarung dazu. Ganz schlecht so was. Aber was will man von einer Firma erwarten, die über dubiose Methoden groß wurde: http://www.tomshardware.de/foren/239832-78-fernwartungssoftware-team-viewer.

Es geht nur ums Geld
Wie Eingangs erwähnt, war auch ich der Meinung – wie viele andere auch – es handelt sich um eine kleine schwäbische Firma die zu Weltruhm gelangte. Aber weit gefehlt. Durch eine Meldung auf Heise http://www.heise.de/newsticker/meldung/Fernwartungsspezialist-TeamViewer-unter-neuem-Eigentuemer-2250174.html etwas nachdenklich, was bei einem Unternehmen eine Milliarde Dollar wert sein kann, fing ich doch mal an näher zu schauen. Zumal die Software an einem Wochenende im Jahr 2005 entstanden sein soll: http://www.tentakel-tech.de/?p=592.

Interessant dabei ist, dass Teamviewer bereits am 29.07.2009 verkauft wurde und zwar an die Iapetos Holding GmbH, welche wiederum der GFI Software S.à r.l. in Luxemburg gehört. GFI Software gibt es schon seit Jahren und ist schon bereits zu Windows NT Zeiten aktiv gewesen, wobei die Firma in Luxemburg erst 2009 gegründet wurde und davor unter TV Holding S.à r.l. firmierte. Bereits am 24.07.2009 erhielt die TV Finance LLC ein Darlehen in Höhe von 15 Millionen USD von der Sillicon Valley Bank um den Kauf der Teamviewer GmbH durchzuführen. Bestimmte Finanztransaktionen wurden über die Britischen Jungferninseln (Virgin Islands) vorgenommen, vor allem wurde dazu auch eine Teamviewer Holding in Roadtown auf den Jungferninseln gegründet, die zum 6.12.2012 wieder aufgelöst wurde.

Diese Informationen kann man im Konzernabschluss 2010 der Iapetos Holding GmbH Unterschleißheim im Bundesanzeiger unter https://www.bundesanzeiger.de/ebanzwww/wexsservlet einsehen. D. h. wer die letzten Jahre brav seine Teamviewer Lizenzen gekauft hat, der hat das Großkapital und keine kleine aufstrebende Firma finanziert.

Jetzt wird mir auch klar, warum verschiedene Dinge so laufen wie sie laufen und dass es Zeit wird sich nach Alternativen umzuschauen. Zumal auch versucht wird die Marke Teamviewer auszuschlachten, indem man andere Produkte wie ITBrains und Cloudbackup anbietet. Wenn man der Meldung des neuen Eigentümers “Permira funds” glauben schenkt, dann werden die 500 Millionen Teamviewer Benutzer nun bearbeitet (“growth plans, … further penetration of its core customer…). Es wurden also 2 USD pro Benuter bezahlt. Blöd nur, dass Permira noch nicht mitbekommen hat, dass zig Millionen angebliche Benutzer schon lange plattgemacht und formatiert wurden.

Alternativen
Eine Alternative ist Google. OK nicht die beste aber eine. Google kennt eh schon alles und jeden, wer also nichts mehr zu verlieren hat, kann den Chrome Remote Desktop verwenden. http://newyear2006.wordpress.com/2012/05/23/remote-desktop-teamviewer-oder-netviewer-alternative-chromes-remoting-viewer/. Zumal Chrome wohl immer noch einer der sichersten Browser ist. Leider ist es aber keine einfache Lösung auch der Neustart des Remoterechners ist nicht vorgesehen.

Interessant dürfte diese Alternative werden. Scheinbar von Ex-Teamviewermitarbeitern gegründete Firma AnyDesk. http://anydesk.de/remote-desktop. Leider noch ganz am Anfang aber mit vielen Ambitionen, wie Plattformunabhängigkeit und Unterstützung von Neustarts. Momentan sogar noch umsonst.

Und natürlich gibt es wie immer die üblichen Verdächtigen wie VNC in Form von TightVNC, UltraVNC usw.

Stärker wird auch immer FreeRDP, welches ich im Zusammenhang mit der Hyper-V Administration hier schon mal genannt hatte: http://newyear2006.wordpress.com/2014/01/08/auf-virtuelle-maschinen-eines-microsoft-hyper-v-server-2012-r2-mittels-freerdp-zugreifen/.

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.

Windows OEM Key aus BIOS/UEFI bzw. ACPI per Powershell auslesen oder wo kommt der Windowskey für die Aktivierung her?

30 Juni 2014

Letzthin war ich doch etwas geschockt, als es darum ging, einem neuen Rechner Windows 8.1 Update 1 beizubringen. Nicht dass jetzt die Installation unmöglich gewesen wäre aber ein paar Details haben mich etwas stutzig gemacht.

Zunächst muss ich sagen, es handelt sich um einen fertigen ASUS-Tower. Dieser wird mit Windows 7 vorinstalliert ausgeliefert. Da aber Windows 8 drauf sollte und dabei gleich die neueste Fassung mit 8.1 Update 1, wollte ich über die übliche Methode diese Version installieren: http://newyear2006.wordpress.com/2013/09/13/windows-8-1-mit-product-key-von-windows-8-installieren/ indem ich die Installation über einen Microsoft-Demokey vornehmen wollte. Bei der Vorbereitung machte ich mich dann auf die Suche nach dem Windows 8 Key. Aber was soll ich sagen? Es gab keinen! Weder auf dem Tower aufgeklebt noch auf den DVDs oder sonstwo.

OK, es gibt ja die Möglichkeit den Key auf die DVD zu verpacken. Also DVD untersucht und die WIM-Dateien mittels 7zip angeschaut aber nix. Keine Datei mit einem Key. Was geht hier ab?

Ich gebs zu, ich hab dann doch von der Original-DVD Windows 8 installiert. Aber nur um zu sehen, ob später ein Key eingetragen ist. Siehe da, die Installation flutscht durch, ohne nach dem Key zu fragen und führt bei Internetverbindung gleich noch die Aktivierung durch. Das nenn ich ja mal Service! Aber genau diesen Service möchte ich am allerwenigsten.

Die Herausforderung
Jetzt wird es aber interessant. Also auf der DVD ist kein Key zu finden. Aber Windows ist nach der Installation aktiviert. Wie geht das? Wo kommt der Key für die Aktivierung her? Hat es Microsoft etwa eingesehen, dass dieses ganze Zwangsaktivierungsgedöns langfristig deren Untergang ist und aktiviert einfach so? Oder ist die Sache irgendwie an das ASUS-Bios bzw. ASUS UEFI Umgebung gebunden?

Mit der letzten Vermutung kommen wir der Sache näher aber zu meiner Überraschung ganz anders, als ich ursprünglich gedacht hatte. Es hat tatsächlich etwas mit UEFI zu tun aber es wird nicht einfach ein Hersteller ermittelt und dieser freigeschaltet, sondern jeder Rechner bringt seinen eigenen Key im ACPI mit! Dies ist auch keine Besonderheit von ASUS sondern alle Hersteller LENOVO, ACER, DELL usw. alle scheinen diese Variante mittlerweile zu praktizieren!

Die verfügbaren Tools
Hier der erste Artikel bei dem ich über die Sache gestolpert bin: http://www.zdnet.com/will-bios-embedded-windows-8-product-keys-cause-reinstall-troubles-7000008226/. Dieser bestätigte also schon mal, dass es tatsächlich so ist, dass der OEM-Key im BIOS hinterlegt ist. Dann ging es weiter: Wenn der da hinterlegt wird, dann kann man den ja irgendwie auslesen: http://www.nextofwindows.com/how-to-retrieve-windows-8-oem-product-key-from-bios/. Hier kommt neben den üblichen Verdächtigen wie Nirsoft auch RWEverything (http://rweverything.com/download/) zur Sprache, welches ich bisher noch nicht kannte. Der Link bei nextofwindows hat auch ein Python-Script parat. In diesem Script kommen interessante Win32-Funktionen zum Einsatz um den OEM-Key auszulesen! Hier das Script auf Github: https://github.com/christian-korneck/get_win8key#files. Python ist gut aber Powershell wäre besser! http://www.eightforums.com/installation-setup/35444-laptop-encrypted-key-uefi-bios-how-obtain-iso-2.html hat einen Powershellfetzen und spricht mittels WMI den SoftwareLicensingService an, welcher mittels OA3xOriginalProductKey den Key anscheinend auslesen kann. Nur leider klappte dies bei mir nie!

Die Hintergründe
Microsoft hat scheinbar schon lange die Möglichkeit vorgesehen, Daten aus dem BIOS bzw. aus dem Firmwarebereich auszulesen. So gibt es z. B. die Win32-Funktion EnumSystemFirmwareTables bereits seit Windows XP mit 64-Bit und generell seit Windows Vista. Macht auch Sinn, da ja ab Windows Vista durch die Umstellungen der Systemsicherheit vieles abgeschottet und umgebaut wurde. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724259(v=vs.85).aspx. Mittels EnumSystemFirmwareTables und GetSystemFirmwareTable kann man nun die nötigen Daten aus der Firmware auslesen. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724379(v=vs.85).aspx. Diese Funktionen nutzt auch das Pythonskript um den Key auszulesen.

Dazu gibt es auch eine offizielle Beschreibung der Speicherstruktur: http://msdn.microsoft.com/en-us/library/windows/hardware/dn653305(v=vs.85).aspx. Microsoft nennt es Microsoft Software Licensing Tables, welche im ACPI-Bereich unter den Systembeschreibungstabellen zu finden ist. Das Dokument spezifiziert davon zwei, einmal SLIC-Table und einmal MSDM-Table. Obwohl das Tabellenformat identisch ist, ist der Unterschied, dass SLIC für VolumeLicenseKeys und MSDM für individuelle Keys gedacht ist.

Bei Tests hat sich herausgestellt, dass Lenovo wie Asus und wahrscheinlich die meisten Hardwarehersteller MSDM benutzen. Dies zeigen auch die vielen Scripte, die es zum Auslesen gibt, welche sich ausschließlich immer auf MSDM beziehen. Interessant dabei ist natürlich, dass bei der Herstellung der Rechner jeder einzelne mit seinem individuellen Key versehen wird! Okay, früher waren es die individualisierten Keyaufkleber aber durch diese Methode können ja im Prinzip viel mehr Dinge auf dem Rechner aktiviert oder individualisiert werden. Denken wir jetzt an nichts Böses, sondern einfach mal an die bei der Bestellung hochgeladene, individuelle Startgrafik.

Powershell Fassung
Auf der weiteren Suche nach einer Fassung in Powershell, bin ich über diese Variante gestolpert: http://winaero.com/blog/how-to-get-the-windows-product-key-without-using-third-party-software/. Auf den ersten Blick genau was ich wollte aber leider wird nur wieder der Key aus der Registrierung ausgelesen, wie man es früher gemacht hat.

Diese Variante war auch ganz hilfreich und enthält noch mehr Infos zu verschiedenen Gegebenheiten und verschiedene Sourcecodes und Scripte: http://forums.mydigitallife.info/threads/43788-C-C-VB-NET-Read-MSDM-license-information-from-BIOS-ACPI-tables/page3.

Aber am Ende war keine Powershellfassung dabei. Also selber machen! Warum eigentlich Powershell? Ja warum? Weil Powershell wird solange da sein, wie sich Microsoft über Wasser halten kann und es ist bei jedem neuen Rechner von Haus aus mit an Bord! Sogar Windows RT bringt es mit. In der reinen Lehre gibt es also nichts anderes.

Also hier der Code:

$SFTCode = @"

 

[DllImport("kernel32")] public static extern uint EnumSystemFirmwareTables (uint FirmwareTableProviderSignature, IntPtr pFirmwareTableBuffer, uint BufferSize);

[DllImport("kernel32")] public static extern uint GetSystemFirmwareTable   (uint FirmwareTableProviderSignature, uint FimrwareTableID, IntPtr pFirmwareTableBuffer, uint BufferSize);

 

"@

 

$SFT = Add-Type -MemberDefinition $SFTCode -Name "SFTKlasse" -Language CSharp -UsingNamespace "System.Reflection", "System.Diagnostics", "System.Collections.Generic" -PassThru

 

# 0×41435049=ACPI ? https://github.com/michaelforney/coreboot/blob/master/src/include/cbmem.h

$firmwareTableProviderSignature = 0×41435049

$StructSize = $SFT::EnumSystemFirmwareTables($firmwareTableProviderSignature, [IntPtr]::Zero, 0)

try

{

    $StructPtr = [Runtime.InteropServices.Marshal]::AllocHGlobal($StructSize)

}

catch [OutOfMemoryException]

{

    throw Error[0]

}

 

$buffer = New-Object Byte[]($StructSize)

$SFT::EnumSystemFirmwareTables($firmwareTableProviderSignature, $StructPtr, $StructSize)

[Runtime.InteropServices.Marshal]::Copy($StructPtr, $buffer, 0, $StructSize)

[Runtime.InteropServices.Marshal]::FreeHGlobal($StructPtr)

 

if (([System.Text.Encoding]::ASCII).GetString($buffer).Contains("MSDM"))

{

    $firmwareTableMSDMID = 0x4d44534d

 

    $StructSize = $SFT::GetSystemFirmwareTable($firmwareTableProviderSignature, $firmwareTableMSDMID, [IntPtr]::Zero, 0)

    try

    {

        $StructPtr = [Runtime.InteropServices.Marshal]::AllocHGlobal($StructSize)

    }

    catch [OutOfMemoryException]

    {

        throw Error[0]

    }

 

    $buffer = New-Object Byte[]($StructSize)

    $SFT::GetSystemFirmwareTable($firmwareTableProviderSignature, $firmwareTableMSDMID, $StructPtr, $StructSize)

    [Runtime.InteropServices.Marshal]::Copy($StructPtr, $buffer, 0, $StructSize)

    [Runtime.InteropServices.Marshal]::FreeHGlobal($StructPtr)

 

    $encoding = [System.Text.Encoding]::GetEncoding(0x4e4)

 

    $key = $encoding.GetString($buffer, 56, 29)

}

$key

Wie immer gilt, von der Formatierung nicht abschrecken lassen, sondern einfach Copy&Paste und loslegen. Übrigens es werden keine Admin-Rechte benötigt! Da einiges durcheinander geht, hier noch der Gist-Verweis: https://gist.github.com/newyear2006/5578386bf4793a334f85#file-getacpi-oemkey-ps1

Würde mich freuen, wenn der eine oder andere seine Erfahrungen im Kommentarbereich verewigen könnte, um ein Gefühl dafür zu bekommen, welche Hersteller die Variante unterstützen.

Zusätzlich interessiert mich besonders:

PS > ([System.Text.Encoding]::ASCII).GetString($buffer)

Dies gibt einen String aus, mit den auf dem Rechner verfügbaren Firmwaretabellen.

Noch ein Hinweis:
Falls es nach dem Copy&Paste zu einem Fehler wie diesem hier kommt:

0×41435049 : Die Benennung "0×41435049" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen

Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.

In Zeile:12 Zeichen:35

+ $firmwareTableProviderSignature = 0×41435049

+ ~~~~~~~~~~

+ CategoryInfo : ObjectNotFound: (0×41435049:String) [], CommandNotFoundException

+ FullyQualifiedErrorId : CommandNotFoundException

dann bitte das x bei 0×41434049 löschen und nochmal eingeben. Scheint eine nette Anomalie von WordPress zu sein.

Arbeitsweise von Powershell Desired State Configuration und Infos darüber

25 Mai 2014

Mit Powershell 4.0 hat die sogenannte Desired State Configuration (DSC) Einzug gehalten. Dabei schreibt man nicht ein Script, was wie eingerichtet werden soll, sondern man beschreibt, wie die Konfiguration eines Rechners aussehen soll. Dabei wird das laufende System von einem speziellen Prozess überwacht. Wird von diesem Prozess eine Änderung festgestellt, die nicht der gewünschten Konfiguration entspricht, kann automatisch ein Reparaturprozess gestartet werden. Dabei kann man diese Konfigurationen einfach per WSMan auf einzelne Rechner im Netz verteilen.

Hier sehr schöner Artikel, der die Vorgehensweise und vor allem auch ein paar Hintergründe beschreibt, wie die Windows Aufgabenplanung mit eingesetzt wird: http://www.verboon.info/2013/11/powershell-desire-state-configuration-my-first-experiences/

Momentan ist DSC noch nicht voll ausgereift aber die Grundlagen sind gelegt und das nötige Ökosystem entwickelt sich schnell.

Bei der Einrichtung zu beachten:

On Windows 8.1 and Windows Server 2012 R2, make certain that KB2883200 is installed or DSC will not work. On Windows Server 2008 R2, Windows 7, and Windows Server 2008, be sure to install the full Microsoft .NET Framework 4.5 package prior to installing WMF 4.0 or DSC may not work correctly.

Ein kleines eBook über DSC: https://onedrive.live.com/?cid=7F868AA697B937FE&id=7F868AA697B937FE%21110

Einführungsvideo mit Erklärungen zur Infrastruktur im Netzwerk und Einsatz mit Linux: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B417#fbid=

Wenn man Probleme hat, hilft unter Windows:

Get-WinEvent –LogName "Microsoft-Windows-Dsc/Operational"

Teamviewer unter Windows 7 und Windows 8 (8.1) bei aktivierter Benutzerkontensteuerung optimal nutzen–ohne Adminrechte für Benutzer

22 Mai 2014

Diese Beschreibung geht auf einen speziellen Sachverhalt ein, welcher oft bei der Einrichtung und Betreuung von Rechnern von Kunden untergeht. Das Problem ist, der Kunde soll möglichst einfach seinen Teamviewer, vornehmlich den Quicksupport öffnen können. Dabei sollte es aber für den Supporter möglich sein, im Zweifelsfall Systemeinstellungen auf dem ferngewarteten Rechner vorzunehmen. Dies impliziert nun einen Admin-Account. Da der Benutzer in der Regel nicht mit Adminrechten ausgestattet sein soll und in den meisten Fällen auch keine Kenntnis von einem Adminpasswort haben soll, hat man ein Problem.

Damit die hier geschilderte Lösung funktioniert, muss man zumindest einmal zur Einrichtung Adminrechte bekommen oder es müssen einem das Adminkonto und das zugehörige Passwort bekannt sein. Alle späteren Fernwartungen laufen dann für den Benutzer mit normalen Rechten ab.

Hier der generelle Ablauf einer Sitzung:
Der Benutzer startet seinen Teamviewer-Quicksupport ohne spezielle Rechte. Dieser verbindet sich mit dem Teamviewerserver, zeigt seine ID und das Kennwort an. Der Status des Fensters lautet:

Bereit zum Verbinden (Sichere Verbindung)

Nun gibt der Benutzer dem Supporter die ID und das Kennwort durch, der Supporter verbindet sich mit dem fernen Rechner und der Benutzer bekommt

Warte auf Authentifizierung

angezeigt.

Der Supporter, anstatt das Kennwort einzugeben, klickt auf “+ Erweitert” unten links und wählt bei Authentifizierung Windows aus. Nun kann man man den Benutzernamen und Kennwort eines lokalen Adminbenutzers des fernen Rechners eingeben. Daraufhin wird die aktuelle Verbindung beendet und beim Teamviewer des Supporters wird kurz

Bitte warten, der Teamviewer Ihres Partners wird mit erhöhten Rechten gestartet.

angezeigt. Der Benutzer am ferngewarteten Rechner sieht darauf hin einen UAC-Dialog, also die Aufforderung mit

Möchten Sie zulassen, dass durch das folgende Programm Änderungen an diesem Computer vorgenommen werden?

Programmname: Teamviewer

Erst wenn der Benutzer hier auf Ja klickt, wird die Fernwartungsverbindung aufgebaut und der Supporter hat nun vollen Zugriff!

Ein Punkt der noch wichtig ist: Teamviewer verlangt bei den Anmeldungen über ein Windowskonto eine Mindestpasswortlänge von 8 Zeichen! Je mehr desto besser natürlich. Wer für diese Aktion einen speziellen Benutzer einrichtet, der nicht unbedingt am Anmeldebildschirm auftauchen soll, der beachte diesen Artikel: http://newyear2006.wordpress.com/2014/05/22/automatische-anmeldung-von-benutzern-und-benutzerkonten-verstecken-bzw-ausblenden/

Automatische Anmeldung von Benutzern und Benutzerkonten verstecken bzw. ausblenden

22 Mai 2014

Um den Zugang zu Windows einfacher zu gestalten, ist es manchmal sinnvoll, für unbedarfte Benutzer seinen eigenen ServiceAdmin-Account vom Anmeldebildschirm zu verbannen.

Das Konto bleibt aktiv, kann aber bei Ausführung dieses Befehls ausgeblendet werden:

reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\W
inlogon\SpecialAccounts\UserList" /t reg_DWord /v ServiceAdmin /d 0

Möchte man den Account wieder angezeigt bekommen, muss man einfach die letzte 0 durch eine 1 ersetzen und den Vorgang nochmal durchführen.

Und wenn wir gerade beim Anmeldebildschirm sind. Nach dem Windows 8.1 Update Update landet man nun ja endlich wieder direkt auf dem Desktop. Aber den einen oder anderen Benutzer stört es noch, vorweg ein Passwort eingeben zu müssen. Kein Problem. Mittels

control userpasswords2

öffnet sich ein Dialog, über den dies geändert werden kann. Dürfte allerdings nur außerhalb von Domänen funktionieren. Dazu muss man nur bei “Benutzer müssen Benutzernamen und Kennwort eingeben” das Häkchen entfernen und den anschließenden Dialog bedienen.

Dieser Artikel greift einen alten Beitrag auf: http://newyear2006.wordpress.com/2008/01/24/aspnet-machine-account-und-automatisches-anmelden-eines-benutzers-unter-windows-xp/

Hier gibt es noch eine bebilderte Anleitung für die automatische Anmeldung: http://www.windowspower.de/ohne-passworteingabe-anmelden-unter-windows-8_12028.html


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.