Frage:

Ich haben einen Rechner der in einem Netzwerk mit einer Domain steht, selbst aber nicht in dieser Domain eingeloggt ist. Verbinde ich nun Laufwerke oder Drucker aus dieser Domain so funktioniert das zwar super, allerdings werden die Passwörter von Zeit zu Zeit anscheinend „vergessen“ – bei den Druckern wirkt sich das so aus, dass diese bei einem Rechnerneustart plötzlich „offline“ sind und ich keinen Weg finde sie wieder auf „online“ zu stellen (Windows 7) – weiters gibt es keinen Dialog, der User und Passwort abfragen würde.

Antwort:

Beim „vergessen“ der Passwörter kann es auch sein dass sich die Passwörter geändert hätten, aber wir haben auch schon beobachtet, dass es nach ein paar Logins einfach nicht mehr geht und der User nicht erneut nach LoginDaten gefragt wird.
Es gibt aber ein einfaches Programm als Windows Bordmittel mit dem man die User und Passwörter zu entfernten Rechnern verwalten kann – dabei ist nur der Rechnername und das Passwort notwendig, der Drucker oder auch die Dateifreigabe verwendet diese Daten dann selbständig.
Aufruf unter „Ausführen“ oder in der Commandline:

rundll32.exe keymgr.dll,KRShowKeyMgr

Der Dialog ist selbserklärend und hier können auch alte nicht mehr benötigte User/Passwort-Kombis rausgeworfen werden.

Unter Windows XP und Server 2003 können nur normale User verwaltet werden, ab Vista, Windows 7, Server 2008 können auch User für Internetseiten an dieser Stelle verwaltet werden und zusätzlich können die Daten für den Transfer auf einen weiteren Rechner auch gesichert und wieder hergestellt werden!

Weitere Tags: „Netzlaufwerk verbinden“, „remove saved Passwords“, „gespeicherte Passwörter entfernen“, „gespeicherte Passwörter löschen“

Frage eines Kunden: Ich wollte meine WordPress Installation mit dem Button ‚Autoupdate‘ auf den neuesten Stand bringen, es wird jedoch im nächsten Dialog nach einem FTP/SFTP-User gefragt.
Gebe ich meine Zugangsdaten an dieser Stelle ein, kommt im nächsten Schritt folgende Fehlermeldung:

WordPress Verzeichnis kann nicht gefunden werden.
Die Installation ging schief

Es gibt keine weiteren Hinweise was genau schief gegangen ist oder wie es zu beheben sei – auch im Error-Log des Webservers kommt keine weitere Fehlermeldung.

Lösung: (möglicherweise graz4u-spezivisch)
Schon die Frage nach der Authentifizierung ist laut WordPress nicht so vorgesehen – wenn diese Meldung erscheint, weist dass auf eine falsche Berechtigung im Verzeichnissystem hin.
Die Vorgabe von WordPress (zumindest für Autoupdate) ist, dass alle Dateien dem selben User gehören, der auch den Webserver ausführt. (im Fall von graz4u.at immer wwrun)

Und tatsächlich war es in diesem Fall so, dass ein longlisting der betroffenen Installation ca. so ausgesehen hat:

 ls -l

-rw-rw---- 1 user-01 gruppe-01·· 236 May 27 15:31 .htaccess
drwxr-s--- 2 user-01 gruppe-01· 4096 May 24 12:03 daten
-rw-r--r-- 1 user-01 gruppe-01·· 397 May 27 14:55 index.php
-rw-r--r-- 1 user-01 gruppe-01 15606 May 27 14:55 license.txt
-rw-r--r-- 1 user-01 gruppe-01 10260 May 27 14:55 liesmich.html
-rw-r--r-- 1 user-01 gruppe-01· 9202 May 27 14:55 readme.html
-rw-r--r-- 1 user-01 gruppe-01· 4337 May 27 14:55 wp-activate.php
drwxrws--- 9 user-01 gruppe-01· 4096 Apr 27 11:38 wp-admi

Die Ausführung von WordPress ist daurch nicht gestört, aber das Autoupdate-Scripot versagt an dieser Stelle…

Folgende Befehle durch den Admin setzten zuerst den User wie von WordPress gewünscht auf den des Webservers und geben der Gruppe auch noch die Schreibrechte, so dass der User „user-01“ auch weiterhin Dateien mittels ftp oder ssh editieren kann. (sofern dies überhaupt benötigt wird)

 chown -R wwwrun:gruppe-01 * 
 chmod -R g+w *
 
 ls -l

-rw-rw---- 1 wwwrun gruppe-01·· 236 May 27 15:31 .htaccess
drwxrws--- 2 wwwrun gruppe-01· 4096 May 24 12:03 daten
-rw-rw-r-- 1 wwwrun gruppe-01·· 397 May 27 14:55 index.php
-rw-rw-r-- 1 wwwrun gruppe-01 15606 May 27 14:55 license.txt
-rw-rw-r-- 1 wwwrun gruppe-01 10260 May 27 14:55 liesmich.html
-rw-rw-r-- 1 wwwrun gruppe-01· 9202 May 27 14:55 readme.html
-rw-rw-r-- 1 wwwrun gruppe-01· 4337 May 27 14:55 wp-activate.php
drwxrws--- 9 wwwrun gruppe-01· 4096 Apr 27 11:38 wp-admi

Danach klappt dann auch das Update gleich beim ersten Klick:

Na toll, Windows 2003 installiert, TerminalServer konfiguriert und dann noch ganz frisch Citrix 4.5 drauf und danach kommt die große Verwunderung: die nagelneue „Citrix Delivery Service Console“ lässt sich weder irgendwie konfigurieren, noch findet sie mir AutoDiscovery irgend etwas im System.
Die „Citrix Erweiterte XenApp-Konfiguration“ verweist an allen möglichen Stellen auf „Konsole starten“ – wenn ebendiese gestartet wird befinden wir uns wieder in der völlig nutzlosen Delvery Service Console…

Soweit so schlecht – mit diesen Werkzeugen ist das System vorerst nicht steuerbar – aber es gibt (direkt von Citrix) eine Erklärung und Abhilfe!

This problem usually presents itself on new installations of XenApp or updates to the Access Management Console or Delivery Services Console; after running a Windows update has been.

OK, muss man das genau verstehen? Das beschriebene Problem presentiert sich also, wenn Citrix inkl. der Management Tools installiert, nachdem man ein Windows-Update gemacht hat? Gibt es denn einen anderen Fall? Oder anders gefragt – wer installiert Citrix auf ein komplett ungepatchtes System?

Na egal, jedenfalls wird im Artikel recht genau beschrieben, welche DLLs man sich zusammen suchen muss um alles wieder neu zu registrieren – und weil das ein öder Job ist und es bei mir gleich so toll funktioniert hat, poste ich hier gleich mal alles auf einen Rutsch – vielleicht kann es ja jemand gebrauchen:

%windir%\microsoft.net\framework\v2.0.50727\regasm /codebase "C:\Programme\Gemeinsame Dateien\citrix\Access Management Console - Dashboard Watcher\DWExtension.dll"
%windir%\microsoft.net\framework\v2.0.50727\regasm /codebase "C:\Programme\Gemeinsame Dateien\citrix\Snap-In 'Presentation Server - Administration'\PSE.Core.dll"
%windir%\microsoft.net\framework\v2.0.50727\regasm /codebase "C:\Programme\Gemeinsame Dateien\citrix\Access Management Console - Diagnostic Facility\CdfExtension.dll"
%windir%\microsoft.net\framework\v2.0.50727\regasm /codebase "C:\Programme\Gemeinsame Dateien\citrix\Access Management Console - Knowledge Base\KnowledgeBaseExtension.dll"
%windir%\microsoft.net\framework\v2.0.50727\regasm /codebase "C:\Programme\Gemeinsame Dateien\citrix\Access Management Console - Hotfix Management\HotfixExtension.dll"
%windir%\microsoft.net\framework\v2.0.50727\regasm /codebase "C:\Programme\Gemeinsame Dateien\citrix\Access Management Console - Legacy Tools\MMCPlugIns\LegacyToolsExt\CMCLaunchExtension.dll"
%windir%\microsoft.net\framework\v2.0.50727\regasm /codebase "C:\Programme\Gemeinsame Dateien\citrix\Access Management Console - Report Center\ReportCentreExtension.dll"

Nach jedem dieser Befehle sollte folgende Erfolgsmeldung kommen:

Microsoft (R) .NET Framework Assembly Registration Utility 2.0.50727.3053
Copyright (C) Microsoft Corporation 1998-2004. Alle Rechte vorbehalten.

Die Typen wurden registriert.

Und danach? Nach einem neuerlichen Öffnen der „Citrix Delivery Service Console“ sieht das Bild schon eher wie im Screenshot von Citrix aus und nun erhalten wir mit der rechten Maus auf „Citrix Delivery Service Console“ auch einen neuen Menüpunkt „Discovery konfigurieren und durchführen“ – Hurra, wir haben unser System wieder in der Hand!

Sollte die Konsole bei Ihnen nicht „Citrix Delivery Service Console“ sondern „Citrix Access Management Console“ benannt sein, sollte das übrigens keine Rolle spielen.

Hier zur Vollstängkeit noch die Ansicht nach dem Discovery:

Frage: Beim Versuch meinen Netzwerkdrucker unter Windows 7 zu verbinden bekomme ich folgende Fehlermeldung: (Fehler bei Vorgang: 0x0000000a.)

Antwort: Das liegt höchstwahrscheinlich daran, dass am Druckserver kein 64bit Treiber für Windows 7 hinterlegt ist.
Windows lädt dann anscheinend den vorhandenen 32bit-Treiber und erzeugt dann die genannte Fehlermeldung.

Abhilfe:

a.) Wie Sie sich als User helfen können:

Den jeweiligen Druckertreiber für 64bit vom Hersteller downloaden und z.B. über den Umweg eines lokalen Druckers (LPT1) installieren. (Dieser Drucker muss ja nicht wirklich angeschlossen sein, und kann später wieder gelöscht werden) – dies gilt für die Netzwerktreiberversionen der Hersteller (ohne Setup, nur Inf-Dateien)
Wird der Treiber über eine setup.exe installiert, kann man den Umweg über den lokalen Drucker weglassen.

Ein „Drucker hinzufügen“ und dann „Treiber aus einer Liste wählen“ scheint nicht möglich zu sein, da der falsche Treiber immer bereits zuvor vom Server geladen wird.

Wird danach der Netzwerkdrucker nochmals hinzugefügt, wird der lokale (richtige) Treiber verwendet und dann sollte auch alles funktionieren!

Sie können die Information aber auch an Ihren Administrator weitergeben – dieser kann dann am Server gleich die richtigen Dateien hinterlegen – siehe Lösung b.)

b.) Wie Sie das Problem als Adminstrator des Druckservers lösen können:

Laden Sie den jeweilgen 64bit Treiber vom Hersteller herunter und achten Sie darauf, dass Sie die Netzwerkfägige Version erwischen – eine Setup-Datei funktioniert hier nicht – es muss sich um ein Verzeichnis mit einer INF-Datei handeln.

Gehen Sie dann in den Eigenschaften des freigegebenen Druckers auf den Tab „Freigabe“ und „Zusätzliche Treiber“

Markieren Sie dort die Checkbox „64bit“ (Windows 7 ist hier nicht aufgelistet – aber das soll uns nicht stören)

nach einem „OK“ kommen Sie dann in einen „hinzufügen-Dialog“ in dem Sie dann das Verzeichnis mit der INF-Datei angeben können – danach werden alle Daten auf den Server kopiert und für die nächste 64bit Installation bereit gehalten.
Achtung – dieser Vorgang kann NICHT durch einfaches unckeck rückgängig gemacht werden!