auer

Du wirst eine veraltete MSInstaller-Version haben, da gibt es ein bekanntes Problem mit der MSDAIPP.DLL, die genau diese Fehlermeldung produziert. Der Text hat scheinbar nichts mit deinem Problem zu tun, in solchen Fällen ist meistens jedoch diese interne Fehlermeldung entscheidend. Näheres unter http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=5c011c70-47d0-4306-9fa4-8e92d36332fe. ------------- Gruß, Auer

Alle Daten als Normaluser sichern, den Rechner frisch aufsetzen und neue Passwörter vergeben - dann ist die Sache erledigt. ------------- Gruß, Auer

Deinstallationen setzen normalerweise Adminrechte voraus - haben dies deine Nutzer? Die Deinstallation beginnt mit der Befehlsfolge, die in der Reg unter Uninstall abgelegt ist. Meistens sind dann Bestätigungen notwendig. Weshalb willst Du das automatisieren? ------------- Gruß, Auer

Es gibt del /s /q *.tmp - mit del /? erfährst Du genaueres. Das ganze als Batch vom at oder Taskplaner ausführen lassen. ------------- Gruß, Auer

Da meiner noch fehlt: Sygate Personal Firewall. Erst kostenlos für privat, inzwischen die Pro-Version für lau, da ich den Rechner beruflich nutze. ------------- Gruß, Auer

Eine heftige Netzlast hat bereits Office97 - Access erzeugt, ob auf älteren Systemen, weiß ich nicht (kein Test), aber auf W2K war ein analoges Phänomen zu beobachten: Nichts getan, teilweise 100% -Prozessorauslastung. Das wurde erst mit Office2000 besser, weil Microsoft ab dann die ADO-Techniken verwendet hat. Insofern fürchte ich, daß Du entweder beim alten System bleiben oder irgendwann jemand das System neu entwickeln muß. ------------- Gruß, Auer

Soeben bei Microsoft nach spnregister 1355 gesucht, dort gibt es http://support.microsoft.com/default.aspx?scid=kb;en-us;303411 mit dem Hinweis: 'This message is not an error message' - Problem erledigt. ------------- Gruß, Auer

Wenn das Problem nur bei einem Profil auftaucht: Richte ein neues Profil ein, bevor Du dich dusselig suchst. Eine Neuinstallation ist nicht notwendig. ------------- Gruß, Auer

Der MSSQLSERVER verwendet standardmäßig den Port 1433. Es sieht so aus, als ob dieser Port bereits von einem anderen Programm belegt sei - zwei Programme können sich nicht einen Port teilen. Suche bei google nach fport. Damit kannst Du dir anzeigen lassen, welches Programm diesen Port belegt. ------------- Gruß, Auer

Das mit den Makros wundert mich etwas. Wenn die 97-Makros von der älteren Version nicht per Hand konvertiert worden sind und stapelweise das ab 97 als 'Billig-Ersatz' eingeführte WordBasic-Objekt verwenden, um älteren Code nicht korrigieren zu müssen, dann hat man tatsächlich ziemlich heftige Anpassungsarbeiten. Bei Makros dagegen, die ab 97 ohne WordBasic-Objekt geschrieben sind, müßte die Konvertierung eigentlich mit einer einmaligen Durchsicht erledigt sein. Der Objektkatalog wurde eben größer, das stört jedoch die bisherigen Objekte nicht. ------------- Gruß, Auer

@Anfaengerin hatte schon die OE-Grafik, das war an dem Symbol links oben erkennbar. Die Outlook-Optionen sehen ziemlich andersartig aus. Wenn @guenterf ebenfalls den IE6 hat wie ich, ist auch das OE dasselbe, bei @Anfaengerin gab es diese beiden bei mir existierenden sicherheitsbezogenen Optionen ja definitiv nicht. Also ist die Option bei dem älteren OE entweder an einer anderen Stelle - dann hilft nur Suchen von dem, der dieselbe Version hat - oder es gibt diese Möglichkeit nicht. Dann hilft evtl. ein Update auf den IE6. ------------- Gruß, Auer

Vorschlag an @Boardadmin: Lösche die beiden Grafiken. Entscheidend: Bei XP gibt es diese zusätzlichen Optionen, bei W2K noch nicht. ------------- Gruß, Auer

Outlook Express mischt sich da tatsächlich ein. Ich kann mir diese Meldung erzeugen, wenn ich aus Access eine Mail versende, entferne ich in OE den Haken, funktioniert dies. Das Problem ist: Mein OE (Win XP, Office XP) sieht so aus, also offenbar anders als deines. Das OE gehört zum Betriebssystem, also scheint es in W2K diesen Haken noch nicht zu geben. ------------ Gruß, Auer

Das ist eine Meldung, die von Outlook Express produziert wird. Entferne dort unter Extras - Optionen - Sicherheit den Haken bei 'Warnung anzeigen, wenn andere Anwendungen versuchen, E-Mail unter meinem Namen zu versenden'. ------------- Gruß, Auer

Die Darstellung von Hex-Ausdrücken mit # ist die Html-Version, in google muß ich statt #003399 nun 0x003399 schreiben. Es genügt ja, wenn google eine Darstellung verarbeitet. Dies händisch umrechnen und mit den entsprechenden Hex-Stellen multiplizieren heißt: 0x00 -> 0 * 256 * 256 0x33 -> 51 * 256 0x99 -> 153 also 0 * 256 * 256 + 51 * 256 + 153 = 13 209. [Nochmal'n Edit] Im SelfHtml gibt es für dieses Problem extra einen Umrechner, aber der ist so tiefliegend, daß man ihn kaum verwendet. Nun kann man's so machen. ------------- Gruß, Auer

Nach kurzem Test und Nachschlagen in der englischen Version (dort gibt es eine Hilfe) stellt sich heraus: Das werde ich bald verwenden. Denn man kann damit Dezimal in Hex und Oktal umrechnen. 240 in Hex (das ist das, was man bei google eingibt) liefert 0xF0 0xF3 in Decimal liefert 243 Das kann man sogar für das hiesige Forum verwenden. Denn für COM-Fehlermeldungen gibt es zwei verschiedene Darstellungen - Hex und als sehr lange Integer, manchmal zeigt Microsoft nur für eine Version ein Suchergebnis an - und zum händischen Umrechnen war ich bislang immer zu faul. 0x8000401A = 2147500058 [Edit] Kleine Ergänzung: Für alle Html / JavaScript-Farbumrechnungen kann man so etwas brauchen, etwa wenn man #003399 als Integer benötigt = 13 209. ------------- Gruß, Auer

Es gibt das 'SAK', wenn ich den Namen richtig weiß. Aber das wird von Firmen wie 1&1 zur Verwaltung gemieteter W2K oder W03-Server angeboten. Sieh dir dort einmal die Server an - da sind Links. Sprich: Für eine Einzelverwendung wohl zu teuer. ------------- Gruß, Auer

Nur als Hinweis: Neulich gab es hier mal einen Thread mit einem ganz merkwürdig abstürzenden Explorer und O2000. Das Ergebnis war, daß ein altes Acrobat 4 dahintersteckte, nach dessen Deinstallation funktionierte alles. ------------- Gruß, Auer

Es gibt irgendeine Funktion zur Erstellung von Zufallszahlen, die bsp. zwischen 0 und 1 liegen. Verwende diese, um zu jedem zu randomisierenden Element ein Zufallselement hinzuzufügen, sortiere dann nach dem Zufallselement. ------------- Gruß, Auer

Solche Meldungen gehen bei DSL direkt an den Port 135. Irgendwann fiel mir dies einmal auf und ich aktivierte mir die Einzelprotokollierung. Da kommt dann so täglich etwa vier Mal ein Hinweis zu Viren (virentest.info), diese Adresse wechselt ständig, ab und an will dann immer jemand für Sexseiten werben. Dem Virentest bin ich mal nachgegangen, lud mir die Datei und führte sie unter einem restriktiven Nutzer ohne Schreibberechtigung aus -> Dialer, der DSL beendete und ISDN-Einwahl versuchte - aber da gab es ja die Rufüberwachung. M.a.W.: Der übliche Quatsch. [Edit] Ups - ich hatte mir zwar alle Beiträge durchgelesen, aber das Datum übersehen. ------------- Gruß, Auer

Der Normal-Öffnungsmodus für Access sieht einen Schreibzugriff vor. Um die Sperren zu koordinieren, wird im Verzeichnis der .MDB - Datei so eine kleine .LDB-Datei angelegt. Diese zu erzeugen bzw. zu bearbeiten wird über den IE nicht gelingen. ------------- Gruß, Auer

Komisch: Müßten nicht bei einem servergespeicherten Profil auch die benutzerspezifischen Reg-Einträge als ntuser.dat auf dem Server liegen? Denn eigentlich heißt doch 'servergespeichertes Profil', daß sich ein Nutzer an verschiedenen Rechnern anmeldet und immer den letzten Bearbeitungsstand vorfindet? ------------- Gruß, Auer

Bei mir gibt es ähnliche Einträge, wenn ich mit der FRITZ!DSL+ISDN online gehe. SVCHOST sendet an 239.255.255.250 und kommuniziert ein paar Mal über die internen Karten mit sich selbst. Als ich dies bei der Einrichtung per FW blockiert hatte, konnte keine Verbindung hergestellt werden, also mußten diese UDP-Ports per FW-Regel freigegeben werden. ------------- Gruß, Auer

Manchmal gehen die Tools von Microsoft merkwürdige Wege. Starte über Start - Ausführen cmd.exe und gib in der entstehenden DosBox net user, dann net localgroup, schließlich net localgroup Administratoren bzw. die bei dir angezeigte andere Version ein. Poste evtl., was bei diesen drei Möglichkeiten herauskommt. ------------- Gruß, Auer

Es kann sein, daß ich das falsch verstanden habe. Wenn die servergespeicherten ntuser.dat nicht schreibgeschützt sind, dann müßte Office die unter HKCU benötigten Schlüssel dort einmalig eintragen und beim nächsten Start auch wieder vorfinden. Dann würde dies nicht das Meckern von Word u.a. erklären. Da ein Nicht-Admin unter HKLM und in den Systemverzeichnissen nichts schreiben muß, um Word ab dem zweiten Start ohne solche Meldungen starten zu können, fallen mir nur zwei Möglichkeiten ein: Office setzt unter HKCU Einträge, diese werden auf den Server geschrieben und sind beim nächsten Mal wieder weg - dann stimmt irgend etwas mit den Server-Zugriffsrechten nicht. Oder Word versucht, irgendwelche Daten in ein lokales Profil zu schreiben, so daß Word nicht kapiert, daß es sich um ein servergespeichertes Profil handelt. Vage Möglichkeit: Mit filemon / regmon von http://www.sysinternals.com Datei- und Regzugriffe überwachen, um das Problem einzugrenzen. Oder prüfen, ob Word irgendwelche lokalen Dateien (.\Application Data bzw. .\Anwendungsdaten) anlegt, die eigentlich auf den Server gehören. Dann prüfen, ob nach dem Start und dem Beenden von Word unter HKCU\Software\Microsoft\Office ein Schlüssel existiert und ob dieser den Rechnerneustart überlebt. ------------- Gruß, Auer