Jump to content

Inno

Members
  • Gesamte Inhalte

    8
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von Inno

Apprentice

Apprentice (3/14)

  • Erste Antwort
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei
  • 1 Jahre dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Da ich selbst nicht der Administratoren-Zunft angehöre sondern mein Geld als Software-Entwickler verdiene sind meine Erfahrungen im Bereich Server-Update eher bescheiden. Ich selbst verwende auf meinem System die Auto-Update Funktion, d.h. wenn's mal ein Update gibt wird es installiert und im Bedarfsfall der Rechner neu gestartet. Treffe ich aber auf besagte Admins, die sich partout weigern, ihre drei Dutzend Server nicht auf dem aktuellen Stand zu halten, kommen über die Windows-Update Funktion schnell 50-60 vorgeschlagene Updates zu Tage. Wenn man das dann mit der Anzahl der Server multipliziert... manches sollte lieber nicht zu Ende gedacht werden.
  2. Möglicherweise sollte man zu diesem Thema einen neuen Thread eröffnen: Was ist der beste Weg, um sein System auf dem neuesten Stand zu halten? Ein Arbeitskollege lässt sich diesbezüglich auf keinerlei Diskussion ein: Jedes Update wird einzeln eingespielt, der Rechner nach jedem Update neu gestartet, anschließend wird das nächste Update installiert, der Rechner neu gestartet usw. Ist dies wirklich notwendig? Ich habe es bereits erlebt, dass Administratoren sich felsenfest weigerten, ihre Systeme upzudaten, da sie gehört hätten, dass in 70% der Fälle nach einem Update ihre Server nicht mehr funktionieren. Wenn man nach "Server Problem nach Update" googelt, erhält man ja so einige Ergebnisse, aber ist es nicht viel gefährlicher, seine Systeme gar nicht zu updaten? Was sagt man einem solchen Administrator in diesem Fall? Was sind eure Erfahrungen/Empfehlungen?
  3. Auf meiner VMWare erscheint wie zu erwarten der DOS-Editor. Auf den Kundenrechner habe ich z. Z. keinen Zugriff. Was wäre denn, wenn der DOS-Editor nicht starten würde?
  4. Hallo Community, ich stehe vor dem Problem, dass sich auf einem Kundenrechner unter W2K3 Server keine 16-Bit Anwendungen ausführen lassen. Es handelt sich beim Betriebssystem soweit ich das beurteilen kann um keine spezielle 64-Bit Version. Beim Anklicken der Anwendung passiert einfach gar nichts. Habe zu diesem Thema nur folgenden Beitrag gefunden: Keine Reaktion bei 16-Bit Anwendungen. Auch das Aktivieren der Unterstützung von 16-Bit Anwendungen über die administrativen Vorlagen halfen nicht weiter. Möglicherweise liegt es wie in dem Beitrag beschrieben an einem Hardware-Dongle, ich werde diesbezüglich noch Rücksprache mit dem Kunden halten. Das Ausführen derselben Anwendung auf einer VMWare (ebenfalls W2K3 Server) gab einen Fehler in ntvdm.exe aus. Hat W2K3-Server generell Probleme beim Ausführen von 16-Bit Anwendungen oder liegt es einfach am verwendeten Intel Xeon 3.0 GHz Prozessor? Bin für jeden Ratschlag dankbar!
  5. Hi Muelli, ich hätt hier noch nen Link: .NET-Framework-Tools Da werden die ganzen caspol-Parameter ausführlicher erklärt.
  6. Hallo Community, hat jemand schon mal die Erfahrung gemacht, dass eine .Net-Anwendung sich trotz konfigurierter Vertrauensstellung nicht über ein Netzlaufwerk ausführen ließ? Ich stehe momentan vor oben genanntem Problem: Unsere Software wurde beim Kunden installiert (im Rahmen der Installation wird auch die .Net-Vertrauensstellung per caspol.exe konfiguriert) und nach Starten des Programms erscheint dieser kryptische Fehlerdialog der immer dann auftaucht, wenn keine .Net-Berechtigungen zugewiesen wurden ("Die Anwendung hat einen Ausnahmefehler verursacht, der nicht verarbeitet werden konnte" gefolgt von Prozess- und Thread-ID). Nach Kopieren der Anwendung auf ein lokales Laufwerk ließ sich das Programm problemlos starten. Laut Überprüfung mittels .Net1.1-Konfigurationswizard und 'caspol.exe -lg' ist die Vertrauensstellung korrekt konfiguriert. Auch ein nachträgliches Konfigurieren von Hand mit Hilfe von caspol.exe und dem .Net1.1-Konfigurationswizard schafften bislang keine Abhilfe. Ich habe den Kunden angewiesen, die Anwendung einmal lokal von dem Server auszuführen, auf dem sie installiert ist, um herauszufinden, ob es wirklich an einer fehlerhaften .Net-Konfiguration liegt. Da ich bislang noch keine Rückmeldung erhalten habe, kann ich nicht 100%ig ausschließen, dass das Problem nicht woanders herrührt, darum frage ich einmal nach, ob schonmal jemand derartige Erfahrungen gemacht hat.
  7. Das Konfigurieren der .Net-Berechtigungen würde ich im Rahmen der Installation der Software durch das Setup vornehmen lassen. Vielen Dank für die freundliche Begrüßung :).
  8. Der aus dem 1.1er -Framework bekannte Konfigurations-Wizard kann bei Framework 2.0 nur noch über das SDK installiert werden. Dieses Verhalten ist von Microsoft gewollt, ob es sinnvoll ist, sei jetzt mal dahingestellt... Die .Net-Berechtigungen (.Net-Vertrauensstellung) sind notwendig, um .Net-Anwendungen (oder besser gesagt .Net-Assemblies) über ein Netzlaufwerk ausführen zu können. Wird eine .Net-Anwendung lokal ausgeführt, sind keine .Net-Berechtigungen notwendig. Um die .Net-Vertrauensstellung dennoch ohne installiertes .Net 2.0-SDK konfigurieren zu können, gibt es das Kommandozeilen-Tool "caspol.exe" im Verzeichnis "%windir%\Microsoft.NET\Framework\v2.0.50727". Informationen zu caspol.exe unter folgendem Link: Full Trust für Assemblies mit caspol.exe Die in diesem Artikel enthaltenen Informationen beziehen sich zwar auf das .Net-Framework v1.1.4322, lassen sich aber ohne Probleme auf .Net 2.0 übertragen. Dazu muss capol.exe lediglich aus dem .Net-Framework 2.0-Verzeichnis ausgeführt werden (i. d. R. "%windir%\Microsoft.NET\Framework\v2.0.50727").
×
×
  • Neu erstellen...