FIXIT pour les problèmes d'installation / mises à jour de IE

Dans le message de news jackr13 nous a dit :

Avez-vous lu les remarques de cette KB313222 dans le paragraphe "Je
résous le problème moi-même" au sujet de certains effets négatifs de
cette réinitialisation tels par exemple que la suppression de comptes
utilisateurs du groupe utilisateurs et la nécessité de les rajouter ?

Bonjour
effectivement il parlent de comptes standards dans le groupe utilisateurs,
par contre mes comptes étaient bien présent dans le groupe daministrateur et
il ne parlent pas du dysfonctionnement du groupe administrateur :)

===== Étapes suivantes Après l'exécution de la solution Microsoft (ou
l'application manuelle des étapes), des comptes d'utilisateur standard
peuvent ne plus apparaître dans le journal à l'écran lorsque vous démarrez
l'ordinateur ou lorsque vous voulez changer d'utilisateur. Ce problème se
produit parce que des comptes d'utilisateur standard sont supprimés du
groupe des utilisateurs lors de la réinitialisation des paramètres de
sécurité de Windows. Pour rajouter les comptes d'utilisateur concernés dans
le groupe des utilisateurs, procédez comme suit :
net localgroup users nom_compte /add
==============

--
Laurent [FAQ IE7 : http://faq.ie7.free.fr - www.technicland.com ]
Radioweb Player V5 gratuit : www.radioweb-player.com
Power IE : http://www.technicland.com/powerie6.php3

*Bonjour* !
<utW0aw13JHA.1416@TK2MSFTNGP04.phx.gbl>

Dans le message de news JF nous a dit :

On restaure en mode sans échec depuis le compte admin de secours. Au
besoin on crée un Compte Admin avec ubcd4win (XP). Quelle méthodes
as-tu utilisées ? Une réparation ? Tu devrais l'expliquer pour le cas
où d'autres utilisateurs rencontreraient le problème.

Bonjour

On restaure en mode sans échec depuis le compte admin de secours

C'est pas si simple que cela, mais ta solution nécessite que tu ai plusieurs
comptes admin,

Je pensais au compte Admin de secours, celui utilisé par le mode sans
échec et la console de récupération
C:Documents and SettingsAdministrateur
Note : ce profil est créé lors de la première utilisation du mode sans
échec ou de la cdr.

La commande RUNAS m'a permis de lancer le Fixit depuis un compte sans
pouvoir. Une condition : le compte Administrateur de secours doit avoir
un mot de passe. Une astuce : j'ai du créer un batch contenant la
commande start MicrosoftFixit50198.msi
Et depuis la Console CMD ==>
runas /env /user:administrateur test.bat

et j'en avais deux autres qui etaient bien dans le groupe
administrateur et qui avaient les memes symptomes c'est a dire je ne pouvais
plus :
- Eteindre l'ordinateur

Ni fermer la session je suppose, ce qui aurait permis, s'il s'agit de
XPPRO, d'ouvrir une session administrateur en faisant deux fois
CTL+ALT+Suppr dans la page d'accueil des comptes.

Avant que quelqu'un ne le dise, on peut toujours forcer l'arrêt, ou
couper l'alim, mais on peut comprendre que tu n'étais pas disposé à
cette extrémité. On me disait pourtant, il y a longtemps, dans un élan
de naïveté : "Les machines ? On pourra toujours les débrancher, jamais
elles ne prendront le pouvoir sur nous".

- Restaurer le systeme
- Meme changer l'heure etc...
j'ai essayé :
- De rejouer le hotfix mais impossible je n'avais pas assez de droit
- De creer un nouveau compte admin (idem)

Avec control userpasswords dans le batch j'ai pu créer un compte
SecoursAdmin. Avec les commandes appropriées, on pouvait sans doute
arrêter Windows, revenir à un point de restauration, etc. Rappel : à
condition d'avoir un mot de passe sur "Administrateur" :(

- J'ai modifié les clé de registre pour pouvoir eteindre l'ordi, cela n'a
rien amélioré, j'ai donc du sauvegarder toutes mes données car je me
demandais si j'arriverai a ouvrir une session aprés le reboot.

On a plein de façons de se récupérer, même si le mode sans échec ne
fonctionne pas (vive ubcd4win).

- Heureusement comme j'arrivais encore dans la console d'administration

"Utilisateurs et groupes locaux" en faisant un clic droit sur Poste de
Travail, Gérer ?

alors au bout d'un moment j'ai passé les comptes dans le groupe utilisateur
avec pouvoir, la j'ai recupéré des droits mais pas celui de restaurer (cela
m'a fait donc comprendre que le groupe administrateur avait pris un shoot)
- J'ai essayé de renomer le groupe admin pas d'amelioration
- Enfin avec les droits du groupe utilisateurs avec pouvoir j'ai pu
rejouer Fixit et la ben ca a fonctionner

Excellent.

Bref tu vois la galère et je pense au pauvre utilisateur qui se retrouve dans
la meme situation :(

Tout à fait. Comme ce Fixit est publié, on devrait voir revenir des cas
similaires. Mais pour l'instant nada (à part ta malheureuse expérience)
http://groups.google.fr/group/microsoft.public.internetexplorer.general/search?q13222+OR+917925+OR+949220

En attendant je te remercie pour ces détails, et l'exposé du
contournement que tu as imaginé. Pour contacter les auteurs du Fixit
l'adresse de courrier est à la section "Le problème est-il résolu ?"
http://support.microsoft.com/kb/313222/fr

Pense à préciser le système utilisé, c'est xppro je présume.

--
Salutations, Jean-François

Dans le message de news JF nous a dit :

Je pensais au compte Admin de secours, celui utilisé par le mode sans
échec et la console de récupération
C:Documents and SettingsAdministrateur
Note : ce profil est créé lors de la première utilisation du mode sans
échec ou de la cdr.

En fait ce n'est pas un compte admin de secours c'est un compte admin comme
les autres il est simplement crée pendant l'installation. Sinon comme je le
disais dans mon mail précedent j'ai d'autres comptes admin et ils avaient
les memes symptomes et j'ai aussi essayé ce compte ainsi que de créer de
nouveaux comptes admin, c'est pour cela que je pense que c'est le groupe
admin qui etait corrompu..

La commande RUNAS m'a permis de lancer le Fixit depuis un compte sans
pouvoir. Une condition : le compte Administrateur de secours doit
avoir un mot de passe. Une astuce : j'ai du créer un batch contenant
la commande start MicrosoftFixit50198.msi
Et depuis la Console CMD ==>
runas /env /user:administrateur test.bat
Ni fermer la session je suppose, ce qui aurait permis, s'il s'agit de
XPPRO, d'ouvrir une session administrateur en faisant deux fois
CTL+ALT+Suppr dans la page d'accueil des comptes.

Run as n'aurait pas fonctionné puisqu'il fait appel a des droits de comptes
pour lequel les droits administrateurs ne fonctionnaient plus.

Avec control userpasswords dans le batch j'ai pu créer un compte
SecoursAdmin. Avec les commandes appropriées, on pouvait sans doute
arrêter Windows, revenir à un point de restauration, etc. Rappel : à
condition d'avoir un mot de passe sur "Administrateur" :(

Comme je l'avais mentionné j avais pu creer de nouveaux comptes admin et
c'etait pareil

On a plein de façons de se récupérer, même si le mode sans échec ne
fonctionne pas (vive ubcd4win).

sans droits d'admin c'est difficile :)

Laurent

Salut

Je pensais au compte Admin de secours, celui utilisé par le mode sans
échec et la console de récupération
C:Documents and SettingsAdministrateur
Note : ce profil est créé lors de la première utilisation du mode sans
échec ou de la cdr.

En fait ce n'est pas un compte admin de secours c'est un compte admin
comme les autres il est simplement crée pendant l'installation.

Par "de secours" j'entendais que c'était le compte utilisé par le mode
sans échec et la console de récupération. C'est pour faire le distingo
avec les autres comptes admin que peut avoir l'utilisateur. Il a des
particularités d'accès, par exemple XPHOME ne permet pas de l'utiliser
aussi facilement que XPPRO.

On a plein de façons de se récupérer,
*même si le mode sans échec ne fonctionne pas*
(vive ubcd4win).

sans droits d'admin c'est difficile :)

Si donc même le mode sans échec ne fonctionne pas, ubcd4win permet de
récupérer le registre à partir des copies du SVI ou d'une sauvegarde
Erunt. Ou encore msdart permet de revenir à un point de restauration.
http://fspsa.free.fr/ubcd4win.htm
http://fspsa.free.fr/ubcd4win.htm#erd-commander
http://www.winhelponline.com/blog/restore-registry-hives-system-restore-snapshot-xp/

Pour mémoire, car plus laborieux, récupérer le registre en lignes de
commandes CDR
http://fspsa.free.fr/cdr-svi.htm
C'est plus facile à la souris avec un bartpe ou un CD Live Linux, et
c'est automatique avec msdart.

Ces méthodes sous-entendent qu'on a des points de restauration. Si ce
n'est pas le cas, il reste la restauration d'une sauvegarde Erunt ou
d'une image-disque. Sinon, la réparation globale à partir du CD
d'installation, pour ceux qui l'ont.

Erunt
http://fspsa.free.fr/erunt.htm

--
Salutations, Jean-François
http://fspsa.free.fr/Index-de-la-FAQ-WINXP-de-Panthere-Noire.htm
http://fspsa.free.fr/Capture-Ecran-et-Publication-vers-Newsgroups.htm
http://fspsa.free.fr/Virus-Malwares-Comment-on-se-fait-infecter.htm

Bonjour,

technicland wrote:

Dans le message de news jackr13 nous a dit :

Avez-vous lu les remarques de cette KB313222 dans le paragraphe "Je
résous le problème moi-même" au sujet de certains effets négatifs de
cette réinitialisation tels par exemple que la suppression de
comptes utilisateurs du groupe utilisateurs et la nécessité de les
rajouter ?

Bonjour
effectivement il parlent de comptes standards dans le groupe
utilisateurs, par contre mes comptes étaient bien présent dans le
groupe daministrateur et il ne parlent pas du dysfonctionnement du
groupe administrateur :)

===== > Étapes suivantes Après l'exécution de la solution Microsoft (ou
l'application manuelle des étapes), des comptes d'utilisateur standard
peuvent ne plus apparaître dans le journal à l'écran lorsque vous
démarrez l'ordinateur ou lorsque vous voulez changer d'utilisateur.
Ce problème se produit parce que des comptes d'utilisateur standard
sont supprimés du groupe des utilisateurs lors de la réinitialisation
des paramètres de sécurité de Windows. Pour rajouter les comptes
d'utilisateur concernés dans le groupe des utilisateurs, procédez
comme suit :
net localgroup users nom_compte /add
==============

Vu.

Peut-être voir le fichier scesrv.log situé dans c:windowssecuritylogs
qui peut vous donner des explications sur les opérations effectuées par
le module secedit.exe lancé par MicrosoftFixIt50198.msi.
Ce fichier se décompose en plusieurs rubriques :
- Configuration des droits utilisateurs,
- Configuration de l'appartenance de groupe,
- Configuation des clés de Registre,
-Configuration de la sécurité des fichiers,
-Configuration des paramètres de services généraux,
-Configuration des moteurs de pièces jointes disponibles,
-Configuration de la stratégie de sécurité,
-Configuration des moteurs de pièces jointes disponibles
-Moteur de configuration de désinstallation...




Personnellement j'ai essayé ce FixIt sur une machine avec XP Pro sp3 et
n'ai apparemment pas eu de problèmes particuliers mais c'était sur une
machine avec une installation assez simple : peu de comptes et peu
d'applications (IE7, FireFox, OpenOffice , AntiVir , etc .. ).
J'ai observé le fichier journal en découlant et n'ai pas vu de problèmes
particuliers si ce n'est plusieurs avertissements 2 pour des fichiers
manquants surtout des dll .
Vu que comptes ASPNET et Invité étaient désactivés.

Cordialement,
Jackr13