Von Legenden und Märchen

Es war einmal… So könnte auch dieses Problem beginnen. Ein ganz fantastisches Phänomen. Fantastisch insofern, als dass es vollkommen unlogisch ist. Microsoft Office 2007, installiert auf einer virtuellen Windows 7 Maschine (Parallels auf einem iMac). Sobald ich mich direkt an der virtuellen Maschine angemeldet hatte, hatte ich ein komplettes Office zur Verfügung. Nach dem Anmelden via Remotedesktop erforderte das selbe Office unter dem selben Benutzerkonto plötzlich eine Aktivierung. Ohne diese war keine volle Funktionalität vorhanden. Und genau diese Aktivierung funktionierte natürlich nicht!

Mehrere Anmelde-Versuche (immer im Wechsel zwischen direkter Anmeldung an der virtuellen Maschine und der Anmeldung via Remotedesktop) ergaben genau das Ergebnis. Direkt -- alles ok, Remote -- keine Chance. Und die Aktivierung mislang.

Die Lösung

Bis ich dann ein Microsoft Office 2007 Programm (z.B. Word) mit administrativen Rechten gestartet hatte. Plötzlich funktionierte die Aktivierung und ward danach nie wieder gesehen…..

Und wenn sie nicht gestorben sind… Willkommen in der Welt der Märchen und Legenden…

www.youtube.com/watch?v=8y9IjOrzfOY

Ich habe wirklich hart kämpfen müssen, obwohl die Lösung ganz einfach war…. Hinterher ist man immer schlauer .

Konfiguration

• Microsoft Windows 7
• Microsoft Visual Studio 2010 Beta 2
• Parallels 4.0
• Apple MacBook

Vorgehensweise

Nachdem die Software auf der virtuellen Maschine installiert war, habe ich den Remotedebugger auf dem Server mit den ASP.NET-Anwendungen installiert und als Dienst gestartet.

Firewallkonfiguration

In der Windows-Firewall muss auf dem Host das Progamm Microsoft Remotedebugger, auf dem Client das Programm Microsoft Visual Studio als Ausnahmen deklariert sein, bzw. in einer Firewall müssen die folgenden Ports geöffnet sein:

• TCP 139
• TCP 445
• UDP 137
• UDP 138

Sollten Sie IPSec benutzen müssen, benötigen Sie auch die folgenden Ports:

• UDP 4500
• UDP 500

Fehlermeldung

Als ich brav alles eingestellt hatte, quittierte mir das System meine Debugging-Bemühungen mit folgender Fehlermeldung:

Unable to start debugging on the web server. The Visual Studio
debugger cannot connect to the remote computer. A firewall may
be preventing communication via DCOM to the remote computer.
Please see Help for assistance.

Remotedebugging - Unable to start debugging on the web server

Diese Fehlermeldung blieb mir selbst bei der Ausschaltung sämtlicher Firewalls erhalten.

Lösung

Der Trick: Mein Netzwerk-Adapter in der Parallels-Maschine war auf “Shared” einstellt und hatte so eine IP, die in einem anderen Netzwerkbereich lag. Da der Domänencontroller diesen nicht kannte, konnte der Microsoft Visual Studio Remotedebugger keine Verbindung zu der Client-Maschine aufbauen.
Setzen Sie den Modus für den Adapter auf “Bridged”. Dann wird es als eigenständige Netzwerkkarte betrachtet und bekommt vom DHCP-Server der Domäne eine eigene IP. Mit dieser kann sich der Remotedebugger dann auch connecten.

Wenn Sie Fragen, Anregungen oder Wünsche zu weiteren Themen in diesem Bereich haben, nutzen Sie bitte die Kommentare. Ich freue mich auf Ihre Feedback…

Hier ein kleiner QuickTipp zwischendurch:

Wie kann ich den DNS-Cache meines Rechners leeren?

Microsoft

ipconfig /flushdns

Apple

• bis Mac OSX 10.4.x:
  lookupd -flushcache
• ab Mac OSX 10.5:
  dscacheutil -flushcache

Manchmal kann es passieren, dass Hintergrundprozesse im MacOS X die CPU-Last hochtreiben, was in einem langsamen, heißen Computer mit blasenden Lüftern endet (besonders bei Laptops). Zu diesen Prozessen gehören u. a. verschiedene Indizierungs-Utilities wie z.B. mds und mdworker. Einer dieser Prozesse ist das aslmanager-Utility, der System-Log-Files -Manager für den “ASL Data Store”, der neu ins OS X eingefügt wurde.

In vergangenen Versionen des MacOS X wurden die System- und Prozess-Log Nachrichten von “syslogd” und dem “syslog” Utility empfangen und verwaltet. Mit MacOS X 10.5.6 hat Apple einen neuen Satz Log Funktionen durch die “ASL” Logging Methode und die API hinzugefügt. Um diese neuen Funktionen kümmert sich der “aslmanger”-Prozess, der direkt nach syslogd gestartet wird.

Apple migriert in zukünftigen Versionen von OS X das bisherige Log Management in die neuen ASL Logging Funktionen, aber es scheinen noch einige bugs in der aktuellen Version der ASL Utilities zu stecken. Während genaue Angaben darüber nicht bekannt sind, sieht es so aus, als bleibt der aslmanager bei bestimmten Funktionen hängen.

Eine Möglichkeit, diesen Umstand zu beseitigen, wäre den Prozess über die Aktivitätsanzeige zu beenden. Das ist aber nur eine vorrübergehende Lösung des Problems und kann Speicher korrumpieren. Anstatt den Prozess also “rauszuschmeißen” wird empfohlen, den Log Management Prozess nach dem Löschen des ASL Data Store Verzeichnisses neu zu starten.

Hoffentlich werden die Bugs im alsmanger in zukünftigen Updates beseitigt.

Lösung

Öffnen Sie das Terminal und geben Sie die folgenden Kommandos ein, um die Log Manager zu stoppen:

• sudo launchctl stop com.apple.syslogd
• sudo launchctl stop com.apple.aslmanager

Legen Sie dann einen Ordner namens temp auf Ihrem Schreibtisch an und geben danach das folgende Kommando in das Terminal ein, der den Inhalt des ASL Data Store in den neuen temporären Ordner verschiebt:

• sudo mv /var/log/asl/* ~/Desktop/temp/

Starten Sie dann den syslogd Prozess mit dem folgenden Kommando (der aslmanager wird erst wieder gestartet, wenn er von syslogd benötigt wird, also braucht er nicht explizit neu gestartet zu werden):

• sudo launchctl start com.apple.syslogd

Dieser Artikel ist die Übersetzung des folgenden Artikels: aslmanager taking up 99% of CPU

Mittlerweile gibt es ganz legal iPhones zu kaufen, die keine Anbieterbindung mehr haben (eBay ist da eine wahre Fundgrube). Allerdings sind dann auch keine Einstellungen gespeichert, die eine Verbindung in ein mobiles Datennetz ermöglichen.

Hier sind die Einstellungen für Vodafone:

Im iPhone auf Einstellungen->Allgemein->Netzwerk->Mobiles Datennetzwerk

Internet

MMS