Problème de droits pour un script VBSCRIPT ou bien anomalie de Err.Number
3 réponses
teddy
Bonjour,
J'ai un script VBScript qui sert à effectuer des sauvegardes, des synchros de répertoires et
finalement reboot un serveur.
Le script est lancé par le gestionnaire de tâches sous le compte ADMIN
Ce script pose - depuis certaines mises à jour de Windows 2000 Server - un problème pour chaque
opération.
En effet, j'ai une erreur 70 "Permission refusée".
Le script fonctionne quand même mais Err.Number retourne cette erreur.
.
Auriez-vous eu le même problème ou bien le Err.Number est défaillant car le script exécute bien les
opérations prévues (vérifié).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gilles LAURENT
" teddy" a écrit dans le message de news: | Bonjour,
Bonjour,
| J'ai un script VBScript qui sert à effectuer des sauvegardes, des | synchros de répertoires et finalement reboot un serveur. | Le script est lancé par le gestionnaire de tâches sous le compte ADMIN | | Ce script pose - depuis certaines mises à jour de Windows 2000 Server | - un problème pour chaque opération. | En effet, j'ai une erreur 70 "Permission refusée". | Le script fonctionne quand même mais Err.Number retourne cette erreur.
Pouvez-vous relancer votre script de manière intéractive en ayant pris soin de mettre en commentaire la ligne "On Error Resume Next". Cela vous permettra certainement de détecter à quel endroit le problème survient.
Tenez nous au courant.
-- Gilles LAURENT http://glsft.free.fr
" teddy" <teddy@orange.com> a écrit dans le message de
news:uh3DoxzDHHA.996@TK2MSFTNGP02.phx.gbl
| Bonjour,
Bonjour,
| J'ai un script VBScript qui sert à effectuer des sauvegardes, des
| synchros de répertoires et finalement reboot un serveur.
| Le script est lancé par le gestionnaire de tâches sous le compte ADMIN
|
| Ce script pose - depuis certaines mises à jour de Windows 2000 Server
| - un problème pour chaque opération.
| En effet, j'ai une erreur 70 "Permission refusée".
| Le script fonctionne quand même mais Err.Number retourne cette erreur.
Pouvez-vous relancer votre script de manière intéractive en ayant pris
soin de mettre en commentaire la ligne "On Error Resume Next". Cela vous
permettra certainement de détecter à quel endroit le problème survient.
" teddy" a écrit dans le message de news: | Bonjour,
Bonjour,
| J'ai un script VBScript qui sert à effectuer des sauvegardes, des | synchros de répertoires et finalement reboot un serveur. | Le script est lancé par le gestionnaire de tâches sous le compte ADMIN | | Ce script pose - depuis certaines mises à jour de Windows 2000 Server | - un problème pour chaque opération. | En effet, j'ai une erreur 70 "Permission refusée". | Le script fonctionne quand même mais Err.Number retourne cette erreur.
Pouvez-vous relancer votre script de manière intéractive en ayant pris soin de mettre en commentaire la ligne "On Error Resume Next". Cela vous permettra certainement de détecter à quel endroit le problème survient.
Tenez nous au courant.
-- Gilles LAURENT http://glsft.free.fr
teddy
Oui, c'est ce que j'ai fait. D'où erreur n° 70 dont la description est "Permission refusée" pour chaque instruction du script. Toutefois, elle s'exécute quand même, comprendra qui pourra ?? Je constate que l'on maîtrise mal les ajouts de sécurité de tout ces "security patches". C'est bien pourquoi dans les entreprises, on ne les applique qu'à moult tests de non régression. Pas de Windows Update que l'on bloque scrupuleusement !
"Gilles LAURENT" a écrit dans le message de news: uTQ$
" teddy" a écrit dans le message de news: | Bonjour,
Bonjour,
| J'ai un script VBScript qui sert à effectuer des sauvegardes, des | synchros de répertoires et finalement reboot un serveur. | Le script est lancé par le gestionnaire de tâches sous le compte ADMIN | | Ce script pose - depuis certaines mises à jour de Windows 2000 Server | - un problème pour chaque opération. | En effet, j'ai une erreur 70 "Permission refusée". | Le script fonctionne quand même mais Err.Number retourne cette erreur.
Pouvez-vous relancer votre script de manière intéractive en ayant pris soin de mettre en commentaire la ligne "On Error Resume Next". Cela vous permettra certainement de détecter à quel endroit le problème survient.
Tenez nous au courant.
-- Gilles LAURENT http://glsft.free.fr
Oui, c'est ce que j'ai fait.
D'où erreur n° 70 dont la description est "Permission refusée" pour chaque
instruction du script.
Toutefois, elle s'exécute quand même, comprendra qui pourra ??
Je constate que l'on maîtrise mal les ajouts de sécurité de tout ces
"security patches".
C'est bien pourquoi dans les entreprises, on ne les applique qu'à moult
tests de non régression.
Pas de Windows Update que l'on bloque scrupuleusement !
"Gilles LAURENT" <glsft@free.fr> a écrit dans le message de news:
uTQ$h98DHHA.4208@TK2MSFTNGP03.phx.gbl...
" teddy" <teddy@orange.com> a écrit dans le message de
news:uh3DoxzDHHA.996@TK2MSFTNGP02.phx.gbl
| Bonjour,
Bonjour,
| J'ai un script VBScript qui sert à effectuer des sauvegardes, des
| synchros de répertoires et finalement reboot un serveur.
| Le script est lancé par le gestionnaire de tâches sous le compte ADMIN
|
| Ce script pose - depuis certaines mises à jour de Windows 2000 Server
| - un problème pour chaque opération.
| En effet, j'ai une erreur 70 "Permission refusée".
| Le script fonctionne quand même mais Err.Number retourne cette erreur.
Pouvez-vous relancer votre script de manière intéractive en ayant pris
soin de mettre en commentaire la ligne "On Error Resume Next". Cela vous
permettra certainement de détecter à quel endroit le problème survient.
Oui, c'est ce que j'ai fait. D'où erreur n° 70 dont la description est "Permission refusée" pour chaque instruction du script. Toutefois, elle s'exécute quand même, comprendra qui pourra ?? Je constate que l'on maîtrise mal les ajouts de sécurité de tout ces "security patches". C'est bien pourquoi dans les entreprises, on ne les applique qu'à moult tests de non régression. Pas de Windows Update que l'on bloque scrupuleusement !
"Gilles LAURENT" a écrit dans le message de news: uTQ$
" teddy" a écrit dans le message de news: | Bonjour,
Bonjour,
| J'ai un script VBScript qui sert à effectuer des sauvegardes, des | synchros de répertoires et finalement reboot un serveur. | Le script est lancé par le gestionnaire de tâches sous le compte ADMIN | | Ce script pose - depuis certaines mises à jour de Windows 2000 Server | - un problème pour chaque opération. | En effet, j'ai une erreur 70 "Permission refusée". | Le script fonctionne quand même mais Err.Number retourne cette erreur.
Pouvez-vous relancer votre script de manière intéractive en ayant pris soin de mettre en commentaire la ligne "On Error Resume Next". Cela vous permettra certainement de détecter à quel endroit le problème survient.
Tenez nous au courant.
-- Gilles LAURENT http://glsft.free.fr
F. Dunoyer [MVP]
Le 26/11/2006, teddy a supposé :
Oui, c'est ce que j'ai fait. D'où erreur n° 70 dont la description est "Permission refusée" pour chaque instruction du script. Toutefois, elle s'exécute quand même, comprendra qui pourra ?? Je constate que l'on maîtrise mal les ajouts de sécurité de tout ces "security patches". C'est bien pourquoi dans les entreprises, on ne les applique qu'à moult tests de non régression. Pas de Windows Update que l'on bloque scrupuleusement !
hummm ca se discute Les raisons du blocage peuvent aussi bien être lié à des raison qui ne sont pas toujours très objectives.
Une des raisons (même si je suis carricatural) c'est : Si je patche et que ça merde je serai tenu responsable Si je ne patche et que ça merde c'est que les vilains dehors ont cassé notre système ...
Une des autres raisons, c'est que, même si je patche, il me faut un crénau où le système, moi et les utilisateurs somment en phase pour arréter et rebooter et parfois c'est difficile à trouver. soit les utilisateurs ont des horaires étendus ou sont repartis, soit les administrateurs ont des horaires réduits lol. Si je n'ai pas ce crénau, c'est dur de passer les patchs.
Une autre raison c'est qu'un fournisseur n'a pas valider le patch (et selon le contrat qu'il a pourquoi passerait il du temps à ça).
et j'en oubli.
Ensuite les patchs corrigent des problemes que vous n'avez peut etre pas ou des failles de sécurités dont certains systèmes sont protégés (enfin un peu) du fait de leur "isolement".
Personnellement j'ai fait mon choix. Je prefère assumer le fait que les mises à jours vont peut être introduire des "perturbations" plutôt que rester une cible.
Mais je précise bien que c'est un choix qui est lié à mes contraintes et à mon environnement.
cdt
-- François Dunoyer [MVP Windows Server / Security] Des liens sur la sécurisation des systèmes Windows http://fds.mvps.org/ta/Liens.htm Site perso : http://www.fdunoyer.net
Le 26/11/2006, teddy a supposé :
Oui, c'est ce que j'ai fait.
D'où erreur n° 70 dont la description est "Permission refusée" pour chaque
instruction du script.
Toutefois, elle s'exécute quand même, comprendra qui pourra ??
Je constate que l'on maîtrise mal les ajouts de sécurité de tout ces
"security patches".
C'est bien pourquoi dans les entreprises, on ne les applique qu'à moult tests
de non régression.
Pas de Windows Update que l'on bloque scrupuleusement !
hummm ca se discute
Les raisons du blocage peuvent aussi bien être lié à des raison qui ne
sont pas toujours très objectives.
Une des raisons (même si je suis carricatural) c'est :
Si je patche et que ça merde je serai tenu responsable
Si je ne patche et que ça merde c'est que les vilains dehors ont cassé
notre système ...
Une des autres raisons, c'est que, même si je patche, il me faut un
crénau où le système, moi et les utilisateurs somment en phase pour
arréter et rebooter et parfois c'est difficile à trouver. soit les
utilisateurs ont des horaires étendus ou sont repartis, soit les
administrateurs ont des horaires réduits lol. Si je n'ai pas ce crénau,
c'est dur de passer les patchs.
Une autre raison c'est qu'un fournisseur n'a pas valider le patch (et
selon le contrat qu'il a pourquoi passerait il du temps à ça).
et j'en oubli.
Ensuite les patchs corrigent des problemes que vous n'avez peut etre
pas ou des failles de sécurités dont certains systèmes sont protégés
(enfin un peu) du fait de leur "isolement".
Personnellement j'ai fait mon choix.
Je prefère assumer le fait que les mises à jours vont peut être
introduire des "perturbations" plutôt que rester une cible.
Mais je précise bien que c'est un choix qui est lié à mes contraintes
et à mon environnement.
cdt
--
François Dunoyer [MVP Windows Server / Security]
Des liens sur la sécurisation des systèmes Windows
http://fds.mvps.org/ta/Liens.htm
Site perso : http://www.fdunoyer.net
Oui, c'est ce que j'ai fait. D'où erreur n° 70 dont la description est "Permission refusée" pour chaque instruction du script. Toutefois, elle s'exécute quand même, comprendra qui pourra ?? Je constate que l'on maîtrise mal les ajouts de sécurité de tout ces "security patches". C'est bien pourquoi dans les entreprises, on ne les applique qu'à moult tests de non régression. Pas de Windows Update que l'on bloque scrupuleusement !
hummm ca se discute Les raisons du blocage peuvent aussi bien être lié à des raison qui ne sont pas toujours très objectives.
Une des raisons (même si je suis carricatural) c'est : Si je patche et que ça merde je serai tenu responsable Si je ne patche et que ça merde c'est que les vilains dehors ont cassé notre système ...
Une des autres raisons, c'est que, même si je patche, il me faut un crénau où le système, moi et les utilisateurs somment en phase pour arréter et rebooter et parfois c'est difficile à trouver. soit les utilisateurs ont des horaires étendus ou sont repartis, soit les administrateurs ont des horaires réduits lol. Si je n'ai pas ce crénau, c'est dur de passer les patchs.
Une autre raison c'est qu'un fournisseur n'a pas valider le patch (et selon le contrat qu'il a pourquoi passerait il du temps à ça).
et j'en oubli.
Ensuite les patchs corrigent des problemes que vous n'avez peut etre pas ou des failles de sécurités dont certains systèmes sont protégés (enfin un peu) du fait de leur "isolement".
Personnellement j'ai fait mon choix. Je prefère assumer le fait que les mises à jours vont peut être introduire des "perturbations" plutôt que rester une cible.
Mais je précise bien que c'est un choix qui est lié à mes contraintes et à mon environnement.
cdt
-- François Dunoyer [MVP Windows Server / Security] Des liens sur la sécurisation des systèmes Windows http://fds.mvps.org/ta/Liens.htm Site perso : http://www.fdunoyer.net
