J'ai posté un message sur microsoft.public.fr.iis mais il est resté sans
réponse.
Il concerne des pages ASP (créées en 2004) écrites en VBScript et portées (à
cause d'un changement d'ordinateur portable) sous VISTA ULTIMATE.
C'est une catastrophe !
Je n'en dis pas plus car ce n'est peut-être pas le bon forum.
Je ne trouve pas ou peu d'aide sur les autres forums et rien ou presque sur
les forums VISTA souvent orientés multimedia ou bien DOT NET.
Ma question : avez-vous l'expérience de IIS 7 et de l'exécution de VBScript
sur cette version ?
Des instructions telles que Server.MapPath(".") ou <!--#include file =
"autrePage.asp" --> génèrent des messages d'erreur et bloquent tout
l'applicatif intranet que je teste sur cette machine VISTA.
Sinon, connaissez-vous un forum qui traite de ces problèmes et des droits à
appliquer ?
Cependant, si tu posais ta question, au lieu de demander si quelqu'un est susceptible de répondre, on pourrait, peut-être, faire quelque chose.
@-salutations
Michel Claveau
teddy
La question était dans le corps du message :
Des instructions telles que Server.MapPath(".") ou <!--#include file = "autrePage.asp" --> génèrent des messages d'erreur "An error occurred on the server when processing the URL. Please contact the system administrator" et bloquent tout l'applicatif intranet que je teste sur cette machine VISTA (faute de continuer sous XP PRO mais j'ai changé de machine).
Avez-vous eu connaissance de ces problèmes; si oui, quelle solutions faut-il mettre en oeuvre ?
"Méta-MCI (MVP)" a écrit dans le message de news:47bdc0ed$0$889$
Bonsoir !
Perso, je n'utilise pas IIS, mais Cherrypy.
Cependant, si tu posais ta question, au lieu de demander si quelqu'un est susceptible de répondre, on pourrait, peut-être, faire quelque chose.
@-salutations
Michel Claveau
La question était dans le corps du message :
Des instructions telles que Server.MapPath(".") ou <!--#include file =
"autrePage.asp" --> génèrent des messages d'erreur "An error occurred on the
server when processing the URL. Please contact the system administrator" et
bloquent tout l'applicatif intranet que je teste sur cette machine VISTA
(faute de continuer sous XP PRO mais j'ai changé de machine).
Avez-vous eu connaissance de ces problèmes; si oui, quelle solutions faut-il
mettre en oeuvre ?
"Méta-MCI (MVP)" <enleverlesX.XmcX@XmclaveauX.com> a écrit dans le message
de news:47bdc0ed$0$889$ba4acef3@news.orange.fr...
Bonsoir !
Perso, je n'utilise pas IIS, mais Cherrypy.
Cependant, si tu posais ta question, au lieu de demander si quelqu'un est
susceptible de répondre, on pourrait, peut-être, faire quelque chose.
Des instructions telles que Server.MapPath(".") ou <!--#include file = "autrePage.asp" --> génèrent des messages d'erreur "An error occurred on the server when processing the URL. Please contact the system administrator" et bloquent tout l'applicatif intranet que je teste sur cette machine VISTA (faute de continuer sous XP PRO mais j'ai changé de machine).
Avez-vous eu connaissance de ces problèmes; si oui, quelle solutions faut-il mettre en oeuvre ?
"Méta-MCI (MVP)" a écrit dans le message de news:47bdc0ed$0$889$
Bonsoir !
Perso, je n'utilise pas IIS, mais Cherrypy.
Cependant, si tu posais ta question, au lieu de demander si quelqu'un est susceptible de répondre, on pourrait, peut-être, faire quelque chose.
@-salutations
Michel Claveau
MCI \(ex do ré Mi chel la si do\) [MVP]
Re !
ça ne me dit rien. Mais le message m'incite à pencher vers un problème de nom du fichier, ou de son emplacement ; mais cela pourrait aussi être lié à des droits d'accès, ou à des caractères atypiques (casse, espaces, accents, etc.)
En fait, en accédant au serveur localement (http:127.0.0.1), ça devrait être vérifié rapidement.
@-salutations
Michel Claveau
Re !
ça ne me dit rien. Mais le message m'incite à pencher vers un problème
de nom du fichier, ou de son emplacement ; mais cela pourrait aussi être
lié à des droits d'accès, ou à des caractères atypiques (casse, espaces,
accents, etc.)
En fait, en accédant au serveur localement (http:\127.0.0.1), ça
devrait être vérifié rapidement.
ça ne me dit rien. Mais le message m'incite à pencher vers un problème de nom du fichier, ou de son emplacement ; mais cela pourrait aussi être lié à des droits d'accès, ou à des caractères atypiques (casse, espaces, accents, etc.)
En fait, en accédant au serveur localement (http:127.0.0.1), ça devrait être vérifié rapidement.
@-salutations
Michel Claveau
teddy
Je pense aussi à des problèmes de droits, mais ce n'est pas facile à résoudre eu égard au manque de clarté et d'ergonomie du gestionnaire IIS7.
J'avais déjà découvert des problèmes sous IIS5.1 avec XP PRO, problème (apparemment) de droits de propriété : un fichier Log - par exemple - créé à l'origine sur le serveur WINDOWS SERVER et recopié sur mon portable sous XP PRO ne pouvait plus être mis à jour d'où un message d'erreur! Si je supprimais ce Log, mon script ASP/VBS le recréait et ça remarchait sans erreur.
Ces mesures pour renforcer la sécurité du serveur amènent beaucoup de problèmes surtout pour le non expert en Administration de serveur.
Teddy
"MCI (ex do ré Mi chel la si do) [MVP]" a écrit dans le message de news:
Re !
ça ne me dit rien. Mais le message m'incite à pencher vers un problème de nom du fichier, ou de son emplacement ; mais cela pourrait aussi être lié à des droits d'accès, ou à des caractères atypiques (casse, espaces, accents, etc.)
En fait, en accédant au serveur localement (http:127.0.0.1), ça devrait être vérifié rapidement.
@-salutations
Michel Claveau
Je pense aussi à des problèmes de droits, mais ce n'est pas facile à
résoudre eu égard au manque de clarté et d'ergonomie du gestionnaire IIS7.
J'avais déjà découvert des problèmes sous IIS5.1 avec XP PRO, problème
(apparemment) de droits de propriété : un fichier Log - par exemple - créé à
l'origine sur le serveur WINDOWS SERVER et recopié sur mon portable sous XP
PRO ne pouvait plus être mis à jour d'où un message d'erreur!
Si je supprimais ce Log, mon script ASP/VBS le recréait et ça remarchait
sans erreur.
Ces mesures pour renforcer la sécurité du serveur amènent beaucoup de
problèmes surtout pour le non expert en Administration de serveur.
Teddy
"MCI (ex do ré Mi chel la si do) [MVP]" <enleverlesO.OmcO@OmclaveauO.com> a
écrit dans le message de news: OMxH9BNdIHA.2268@TK2MSFTNGP02.phx.gbl...
Re !
ça ne me dit rien. Mais le message m'incite à pencher vers un problème de
nom du fichier, ou de son emplacement ; mais cela pourrait aussi être lié
à des droits d'accès, ou à des caractères atypiques (casse, espaces,
accents, etc.)
En fait, en accédant au serveur localement (http:\127.0.0.1), ça devrait
être vérifié rapidement.
Je pense aussi à des problèmes de droits, mais ce n'est pas facile à résoudre eu égard au manque de clarté et d'ergonomie du gestionnaire IIS7.
J'avais déjà découvert des problèmes sous IIS5.1 avec XP PRO, problème (apparemment) de droits de propriété : un fichier Log - par exemple - créé à l'origine sur le serveur WINDOWS SERVER et recopié sur mon portable sous XP PRO ne pouvait plus être mis à jour d'où un message d'erreur! Si je supprimais ce Log, mon script ASP/VBS le recréait et ça remarchait sans erreur.
Ces mesures pour renforcer la sécurité du serveur amènent beaucoup de problèmes surtout pour le non expert en Administration de serveur.
Teddy
"MCI (ex do ré Mi chel la si do) [MVP]" a écrit dans le message de news:
Re !
ça ne me dit rien. Mais le message m'incite à pencher vers un problème de nom du fichier, ou de son emplacement ; mais cela pourrait aussi être lié à des droits d'accès, ou à des caractères atypiques (casse, espaces, accents, etc.)
En fait, en accédant au serveur localement (http:127.0.0.1), ça devrait être vérifié rapidement.
@-salutations
Michel Claveau
jbongran
"MCI (ex do ré Mi chel la si do) [MVP]" a écrit dans le message de news:
Re !
ça ne me dit rien. Mais le message m'incite à pencher vers un problème de nom du fichier, ou de son emplacement ; mais cela pourrait aussi être lié à des droits d'accès, ou à des caractères atypiques (casse, espaces, accents, etc.)
En fait, en accédant au serveur localement (http:127.0.0.1), ça devrait être vérifié rapidement.
@-salutations
Michel Claveau
Répondu dans le groupe iis. Il faut sous IIS 7.0 comme c'est le cas depuis IIS 6.0 autoriser explicitement les chemins parents...
"MCI (ex do ré Mi chel la si do) [MVP]" <enleverlesO.OmcO@OmclaveauO.com> a
écrit dans le message de news:OMxH9BNdIHA.2268@TK2MSFTNGP02.phx.gbl...
Re !
ça ne me dit rien. Mais le message m'incite à pencher vers un problème de
nom du fichier, ou de son emplacement ; mais cela pourrait aussi être lié
à des droits d'accès, ou à des caractères atypiques (casse, espaces,
accents, etc.)
En fait, en accédant au serveur localement (http:\127.0.0.1), ça devrait
être vérifié rapidement.
@-salutations
Michel Claveau
Répondu dans le groupe iis.
Il faut sous IIS 7.0 comme c'est le cas depuis IIS 6.0 autoriser
explicitement les chemins parents...
"MCI (ex do ré Mi chel la si do) [MVP]" a écrit dans le message de news:
Re !
ça ne me dit rien. Mais le message m'incite à pencher vers un problème de nom du fichier, ou de son emplacement ; mais cela pourrait aussi être lié à des droits d'accès, ou à des caractères atypiques (casse, espaces, accents, etc.)
En fait, en accédant au serveur localement (http:127.0.0.1), ça devrait être vérifié rapidement.
@-salutations
Michel Claveau
Répondu dans le groupe iis. Il faut sous IIS 7.0 comme c'est le cas depuis IIS 6.0 autoriser explicitement les chemins parents...
teddy
OK. Je vais revoir tous les droits sur ces répertoires et fichiers.
"jbongran" a écrit dans le message de news:47c495d3$0$32125$
"MCI (ex do ré Mi chel la si do) [MVP]" a écrit dans le message de news:
Re !
ça ne me dit rien. Mais le message m'incite à pencher vers un problème de nom du fichier, ou de son emplacement ; mais cela pourrait aussi être lié à des droits d'accès, ou à des caractères atypiques (casse, espaces, accents, etc.)
En fait, en accédant au serveur localement (http:127.0.0.1), ça devrait être vérifié rapidement.
@-salutations
Michel Claveau
Répondu dans le groupe iis. Il faut sous IIS 7.0 comme c'est le cas depuis IIS 6.0 autoriser explicitement les chemins parents...
OK.
Je vais revoir tous les droits sur ces répertoires et fichiers.
"jbongran" <jbongran@free.fr> a écrit dans le message de
news:47c495d3$0$32125$426a74cc@news.free.fr...
"MCI (ex do ré Mi chel la si do) [MVP]" <enleverlesO.OmcO@OmclaveauO.com>
a écrit dans le message de news:OMxH9BNdIHA.2268@TK2MSFTNGP02.phx.gbl...
Re !
ça ne me dit rien. Mais le message m'incite à pencher vers un problème de
nom du fichier, ou de son emplacement ; mais cela pourrait aussi être lié
à des droits d'accès, ou à des caractères atypiques (casse, espaces,
accents, etc.)
En fait, en accédant au serveur localement (http:\127.0.0.1), ça devrait
être vérifié rapidement.
@-salutations
Michel Claveau
Répondu dans le groupe iis.
Il faut sous IIS 7.0 comme c'est le cas depuis IIS 6.0 autoriser
explicitement les chemins parents...
OK. Je vais revoir tous les droits sur ces répertoires et fichiers.
"jbongran" a écrit dans le message de news:47c495d3$0$32125$
"MCI (ex do ré Mi chel la si do) [MVP]" a écrit dans le message de news:
Re !
ça ne me dit rien. Mais le message m'incite à pencher vers un problème de nom du fichier, ou de son emplacement ; mais cela pourrait aussi être lié à des droits d'accès, ou à des caractères atypiques (casse, espaces, accents, etc.)
En fait, en accédant au serveur localement (http:127.0.0.1), ça devrait être vérifié rapidement.
@-salutations
Michel Claveau
Répondu dans le groupe iis. Il faut sous IIS 7.0 comme c'est le cas depuis IIS 6.0 autoriser explicitement les chemins parents...
teddy
Tout marche maintenant. Il fallait rajouter le paramètre enableParentPaths="true" ce qui correspond à un fichier config (ou manifest ?) dont le contenu est : <?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <asp enableParentPaths="true" scriptErrorSentToBrowser="true" /> </system.webServer> </configuration>
" teddy" a écrit dans le message de news:eKbB%
Bonjour à tous,
J'ai posté un message sur microsoft.public.fr.iis mais il est resté sans réponse. Il concerne des pages ASP (créées en 2004) écrites en VBScript et portées (à cause d'un changement d'ordinateur portable) sous VISTA ULTIMATE. C'est une catastrophe ! Je n'en dis pas plus car ce n'est peut-être pas le bon forum. Je ne trouve pas ou peu d'aide sur les autres forums et rien ou presque sur les forums VISTA souvent orientés multimedia ou bien DOT NET.
Ma question : avez-vous l'expérience de IIS 7 et de l'exécution de VBScript sur cette version ?
Des instructions telles que Server.MapPath(".") ou <!--#include file = "autrePage.asp" --> génèrent des messages d'erreur et bloquent tout l'applicatif intranet que je teste sur cette machine VISTA. Sinon, connaissez-vous un forum qui traite de ces problèmes et des droits à appliquer ?
Merci beaucoup par avance. Teddy
Tout marche maintenant.
Il fallait rajouter le paramètre enableParentPaths="true" ce qui correspond
à un fichier config (ou manifest ?) dont le contenu est :
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<asp enableParentPaths="true" scriptErrorSentToBrowser="true" />
</system.webServer>
</configuration>
" teddy" <teddy@wanadoo.fr> a écrit dans le message de
news:eKbB%23SzcIHA.1168@TK2MSFTNGP02.phx.gbl...
Bonjour à tous,
J'ai posté un message sur microsoft.public.fr.iis mais il est resté sans
réponse.
Il concerne des pages ASP (créées en 2004) écrites en VBScript et portées
(à cause d'un changement d'ordinateur portable) sous VISTA ULTIMATE.
C'est une catastrophe !
Je n'en dis pas plus car ce n'est peut-être pas le bon forum.
Je ne trouve pas ou peu d'aide sur les autres forums et rien ou presque
sur les forums VISTA souvent orientés multimedia ou bien DOT NET.
Ma question : avez-vous l'expérience de IIS 7 et de l'exécution de
VBScript sur cette version ?
Des instructions telles que Server.MapPath(".") ou <!--#include file =
"autrePage.asp" --> génèrent des messages d'erreur et bloquent tout
l'applicatif intranet que je teste sur cette machine VISTA.
Sinon, connaissez-vous un forum qui traite de ces problèmes et des droits
à appliquer ?
Tout marche maintenant. Il fallait rajouter le paramètre enableParentPaths="true" ce qui correspond à un fichier config (ou manifest ?) dont le contenu est : <?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <asp enableParentPaths="true" scriptErrorSentToBrowser="true" /> </system.webServer> </configuration>
" teddy" a écrit dans le message de news:eKbB%
Bonjour à tous,
J'ai posté un message sur microsoft.public.fr.iis mais il est resté sans réponse. Il concerne des pages ASP (créées en 2004) écrites en VBScript et portées (à cause d'un changement d'ordinateur portable) sous VISTA ULTIMATE. C'est une catastrophe ! Je n'en dis pas plus car ce n'est peut-être pas le bon forum. Je ne trouve pas ou peu d'aide sur les autres forums et rien ou presque sur les forums VISTA souvent orientés multimedia ou bien DOT NET.
Ma question : avez-vous l'expérience de IIS 7 et de l'exécution de VBScript sur cette version ?
Des instructions telles que Server.MapPath(".") ou <!--#include file = "autrePage.asp" --> génèrent des messages d'erreur et bloquent tout l'applicatif intranet que je teste sur cette machine VISTA. Sinon, connaissez-vous un forum qui traite de ces problèmes et des droits à appliquer ?
