none
Exchange 2010 2008 R2 sp1 Acces IIS powershel impossible RRS feed

 > 

  • Question

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    Je dois intervenir sur un serveur dont certaines fonctionnalités ont été plantée.
    Ce serveur est actif sous exchange 2010 et fonctionne mais ne peux plus être administré.

    l'accès http://127.0.0.1 ne fonctionne plus, pas de réponse.
    le powershell sous IIS ne peut pu être atteint: message  authentification :
    une erreur s'est produite lors de cette opération. pad de code ni de ligne d'erreur.
    Détails : Nom de fichier:\\?\c:\Programs Files\Microsoft\Exchange Server\ClientAccess\Powershell\Web.config Erreur:
    de même Public et sauvegarde sous ISS provoque une erreur du même type, uniquement sur authentification, avec comme ligne : <authentication mode="Windows" />
    en revanche OWA qui accède le même fichier ne provoque pas d'erreur.

    A la lecture des posts sur google, j'ai l'impression que tout tourne autour des autorisations et que le non fonctionnement de Powershell entraine, l'impossibilité de se connecter sur Exchange 2010: accès refusé, ou sur Exchange shell : erreur équivalente.

    J'ai tenté plusieurs actions :
    - suppression de web.config à la racine de wwwroot.
    - modification des authentification mode à None
    - et plusieurs autres aux travers des groupes de news anglais et français.

    je suis également tombé sur ce forum sur le Sujet Exchange 2010 EMC ne fonctionne pas, ou il était suggéré de vérifier les droits par la commande GEt-User, hors cette commande ne fonctionne pas.

    En résumé, je ne peux pas intervenir, sur les modules Powershell dont je suppose que l'origine des problème se trouve là.

    Je me propose de désintaller winRM (Service de Gestion) sous le rôle IIS.
    Et après j'avoue ne pas savoir ou aller sauf à réinstaller le serveur. Procédure longue et couteuse.

    Merci de votre aide.

     

    Cordialement

     

     

     

     

     

    dimanche 18 décembre 2011 14:36
    |

Réponses

  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonjour,

    Je réponds avec un peu de retard.

    Le problème concernant les plantage de powershell est réglé. Il faut vérifier correctement l'installation du module Kerbauth en natif local sous powershell.fa

    Et éventuellement désinstaller, réinstaller winRM pour  régler un éventuelle erreur 500.

    Le problème restant est l'impossiblité de se connecter a OWA, activsync, et OAB. il provoque systèmatiquement une erreur 401.2, avec  dans la log détaillée un e erreur IIS web core Authenticate request accès refusé (0x80070005), le module apppool étant msexchangeowaapppoll. suivi, d'une erreur 401 authorization request - l'opération a réussi et un final staut 302 dans le même apppool mais sur la page owa/auth.owa

    J'ai réinstallé un nouveau serveur dans la même configuration et tout fonctionne sur celui ci.
    pour mémoire : 2008 R2 sp1 Exchange 2010 SP2.
    j'ai donc mis les deux config en parallèle et ai corrigé toutes les autorisations tant au niveau de IIS que au niveau des dossiers et fichiers.
    J'ai revérifié tous les autorisations du répertoire inetsrv dans system32, et me suis assuré que les autorisations et les propriétaire des dossiers et fichiers étaient corrects.

    mais toujours la même erreur. et le répertoire config de inetsrv ne se met pas à jour lors des modifs sur IIS en particulier l'applicationhost.config.

    J'ai sauvegardé mon exchange par "mailboxrequest" et vais restaurer les boites depuis la sauvegarde pst, après avoir recréer les comptes.

    ils faudra que je sorte et que je rentre les utilisateurs dans le domaine, avant de réinstaller les outlooks.

    Beaucoup de travail pour une erreur incompréhensible.

    Je précise que je parcours depuis plusieurs semaines les forums, pour trouver la cause de cette erreur qui est toujours liée à une erreur asp.net 1314 eventid 4007. je crois avoir fait toutes les KB de microsoft sur le sujet ;-) et ai suivi d'autres routes comme une métabase de travers, ainsi que réenregistrement de asp.net.

    Merci de votre aide.

    hugues



    mercredi 22 février 2012 13:53
    |

Toutes les réponses

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    Pouvez vous preciser certains points ?

    Vous etes sous Exchange 2010 est ce que vous avez appliquez le SP1 ? SP2 ? des rollup ?

    C'est une install 1 serveur avec roles CAS/HUB/MBX c'est bien cela ?

    Vous etes sous Windows 2008 R2 SP1

    Au niveau de la console de gestion de IIS est ce que tout fonctionne normalement ?

    Le site web par defaut demarre correctement ?

    Les pools applicatifs tournent tous correctement ? (il n'y en a pas de planté ?)

    OWA fonctionne mais pas l'EMS (le Shell) ainsi que l'EMC (la Console) les 2 plantent c'est bien cela ?

    Je ne comprends pas le http://127.0.0.1 ne fonctionne plus (alors qu'OWA fonctionne) quelle est le message d'erreur ?

    Cordialement,

    Anthony COSTESEQUE

    dimanche 18 décembre 2011 15:21
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour
    et Merci de votre aide.

    Je suis en Exchange  2010 sans sp. appliquées

    C'est une install 1 serveur avec roles CAS/HUB/MBX c'est bien cela ?  Oui

    Vous etes sous Windows 2008 R2 SP1: Oui

    Au niveau de la console de gestion de IIS est ce que tout fonctionne normalement ?
    partiellement, toutes les fonctions sont actives pour toutes les directory sauf, comme indiqué pour Public, sauvegarde.
    Curieusement OWA n'a pas de problème; l'accès à des fonctions donne une erreur sur web.config au niveau de la ligne authorisation, comme indiqué.

    Le site web par défaut démarre correctement ? Oui, mais http://localhost tourne dans le vide et http://localhost/powershel fait un 403.

    Les pools applicatifs tournent tous correctement ? (il n'y en a pas de planté ?) Oui sauf MSExchangePowerShellAppPool qui est arrêté au reset de IIS, mais peut être redémarré par la suite.

    OWA fonctionne mais pas l'EMS (le Shell) ainsi que l'EMC (la Console) les 2 plantent c'est bien cela ?
    OWA ne réponds pas non plus et Effectivement, le Shell et la console renvoient une erreur d'authentification, de type Kerberos, qui devrait être corrigé par une intervention sur les modules du Powershell sous IIS, mais l'accès est impossible.
    de Plus, le module Kerberos, n'apparait pas dans la liste des modules du site web par défaut.

    Je ne comprends pas le http://127.0.0.1 ne fonctionne plus (alors qu'OWA fonctionne) quelle est le message d'erreur ?
    je me suis mal exprimé, il n'y a pas d'erreur sur le répertoire virtuel OWA, alors qu'il y a l'erreur sur Public qui attaque le même fichier web.config mais https://127.0.0.1/owa pédale dans la semoule comme http://127.0.0.1 ou localhost ou ::1.

     

    Bien cordialement

     

    Hugues

     

     

     

     

     

     

    dimanche 18 décembre 2011 17:26
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Pour public, ce n'est qu'une redirection vers owa.

    pour la virtual directory powershell, l'auth doit etre à "anonyme"

    pour owa à "authentification de base"

    pour ecp à "anonyme & authentification de base"

    pour la default web site à "anonyme"

    tout les pools doivent etre demarré

    vérifiez : clique droit sur la default web site > modifier les liaisons

    il ne doit rien y avoir dans toutes les lignes au niveau du "nom de l'hote" (cette case doit toujours etre vide)

    Cordialement,

    Anthony COSTESEQUE

    dimanche 18 décembre 2011 23:41
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonjour Anthony,

     

    Merci de ces précisions. Il y a au moins deux ou trois paramètres qui ne sont pas correctes.

    Des mise à jour étaient en cours et  le serveur a redémarré mais tourne depuis quasi 1 heure sur la préparation de windows suite aux mises à jour.

     

    Je vous tiens au courant des effets des corrections

     

    Bien cordialement

     

    Hugues

     

    lundi 19 décembre 2011 09:53
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

     

    J'ai validé toutes les modifs proposées, sauf une que je ne peux pas appliquer sur l'authentification Powershell.

    le message d'erreur est : une erreur s'est produite lors de cette opération. pas de code ni de ligne d'erreur.
    Détails : Nom de fichier:\\?\c:\Programs Files\Microsoft\Exchange Server\ClientAccess\Powershell\Web.config Erreur:

     

    Cordialement

     

    Hugues

     

     

    lundi 19 décembre 2011 11:32
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Salut,

    1- Reboot le serveur

    2- s'assurer que les paramètres de sécurité sur le répertoire virtuel de Power Shell sont correct c.a.d

    dans le gestionnaire de services IIS >Nom-du serveur > Sites > Site Web par défaut > Power Shell > cliquer droit > pointer sur l'onglet Authentification > et s'assurer que l'accèe  Anonymous  est désactivé > et que l'Authentification Intégrer Windows est Activé

    3- ensuite taper : Get-User <username> et vérifier que RemotePowershellEnabled

    ici Username l'administrateur Exemple

    4 -ensuite taper :

    Set-User “User Name” -RemotePowerShellEnabled $true

    Pour actier le RemotePowershell

    Si le Pb persite encore Alors :

    ouvrir session avec l'admin du  domaine et ouvrir le  Windows PowerShell

    5 - taper cette commande :

    Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

    ensuite :

    Get-PowerShellVirtualDirectory |fl
    Get-PowerShellVirtualDirectory | Remove-PowerShellVirtualDirectory
Remove-PowerShellVirtualDirectory -identity "powershell-vdir "
    

    redémarrer IIS : iisreset
    créer un nouveau répertoire virtuel PowerShell : 
    New-PowerShellVirtualDirectory
Name: PowerShell
    

    redémarrer IIS une autre fois  : iisreset
    désactiver le paramètre "Require SSL" du répertoire virtuel : 
    Set-PowerShellVirtualDirectory -identity "powershell-vdir" -RequireSSL:$false
    

    ensuite dans  le gestionnaire de services IIS >Nom-du serveur > Sites > Site Web par défaut > Power Shell > cliquer droit > pointer sur paramètrage SSL >dans Exiger SSL cliquer à fin de décocher puis ignore et cliquer sur Appliquer >
    tu peux continuer pour régler aussi OWA :
    Get-OwaVirtualDirectory | Remove-OwaVirtualDirectory
    

    redémarrer IIS : iisreset
    Créer de nouveau le répertoire virtuel OWA :
    New-OwaVirtualDirectory
    

    redémarrer IIS : iisreset
    

    et le PB sera résolue
    lundi 19 décembre 2011 17:33
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonsoir,

    1- Reboot le serveur : C'est fait

    2- s'assurer que les paramètres de sécurité sur le répertoire virtuel de Power Shell sont correct c.a.d

    dans le gestionnaire de services IIS >Nom-du serveur > Sites > Site Web par défaut > Power Shell > cliquer droit > pointer sur l'onglet Authentification > et s'assurer que l'accèe  Anonymous  est désactivé > et que l'Authentification Intégrer Windows est Activé

    Je n'ai pas accès à l'onglet (une erreur s'est produite lors de cette opération. pas de code ni de ligne d'erreur.
    Détails : Nom de fichier:\\?\c:\Programs Files\Microsoft\Exchange Server\ClientAccess\Powershell\Web.config Erreur:)

    3- ensuite taper : Get-User <username> et vérifier que RemotePowershellEnabled

    ici Username l'administrateur Exemple

    Cette commande n'est pas reconnue Get-User

    4 -ensuite taper :

    Set-User “User Name” -RemotePowerShellEnabled $true

    Pour actier le RemotePowershell

    Cette commande n'est pas reconnue Get-User

    Il semble que le service CAS exchange soit détérioré. J'ai, en suivant les conseils du support, entamer la désinstallation du CAS exchange. Le problème est que je suis obligé de faire des suppressions de services inexistants rester dans la base de registre, toujours sur le conseil du support Microsoft.

    La démarche suivante serait selon eux la désinstallation réinstallation de CAS puis de IIS.

    Sachant que la solution 5 que vous proposez permettrai peut être d'éviter l'opération sure IIS.

    Y a t'il sur le setup d'exchange un moyen de lancer une réparation de exchange.

    Merci de vote aide

    Cordialement

     

    Hugues

     

     

    lundi 19 décembre 2011 18:23
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonjour,

     

    Bon la situation progresse. après pas mal de difficultés à désinstaller le role CAS  exchange. J'y suis arrivé en mettant les taches exchange en manuel, puis arrêt relance du serveur.

    J'ai désinstallé IIS

    je suis en passe de réinstaller CAS puis IIS

    Je vous tiens au courant

     

    cordialement

     

    Hugues

     

    mardi 20 décembre 2011 07:31
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonjour,

     

    Voici quelques nouvelles.

    Tout d'abords, merci de vos avis et idées pour régler le problème.

    La suppression des VirtualDirectory ne solutionnait pas le problème car les fichiers était conservés.

    Premier constatation: le InstallExchangePath : est très important et doit impérativement être renseigné à

    c/\Program Files\Microsoft\Exchange\v14\ normalement et ceci même si le répertoire s'appelle programmes.
    Sinon c'est l'erreur 500 sur l'exchange Management Console et Powershell.

    Après désinstallation et réinstallation du CAS, pas de changement. Rappel, pour désinstaller le CAS, il faut d'abords désinstaller réinstaller  IIS, puis seulement désinstaller et réinstaller le CAS; si il y a des erreurs de désinstallation, regardez le message, il doit indiquer un module manquant dans le powershell; il faut alors l'installer (ajouté un module managé) puis relancer la desinstallation puis réinstallation.

    Il nous a fallut passer la SP2 d'exchange pour remettre tout en état.

    Depuis tous les modules fonctionnent à l'exception de Exchange et Exchweb, qui font une erreur dans le Web.config OWA
    sur la ligne <authentication mode="Windows" />

    IL me reste un problème à régler qui est que on ne peut pas s'authentifier sur OWA et activsync.

    Les réglages actuels sont :

    pour le CAS OWA dans Exchange: authentification basé sur formulaires ( domaine renseigné)
    dans IIS authentification de base et windows (NTLM et Négociate)

    Et je ne trouve pas la source du problème.

     

    Cordialement

     

    Hugues

     

    vendredi 23 décembre 2011 11:02
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonsoir,

     

    J'avance et est constaté 2 erreurs répétitives dans applications et système. (toutes les 20 secondes)

    Application : IIS-W3SVC-WP eventid 2276 binary 05000780 (acces denied)

    systeme  : WAS eventid 5009  APPPoolid:  DefaultappPool

    De plus  j'ai une erreur chemin non trouvé : dans IIS > paramètres de base > tester les paramètres alors que le chemin est correct. pour passer le test je doit lui indiquer un compte spécifique : administrateur, ce qui n'est pas très bon, au lieu de utilisateur de l'application.

    troisième point en suivant le Guid de l'erreur dans regidit, je tombe sur le module iisres.dll dans windir\systeme32\inetsrv\

    toujours en suivant la piste dans services de composants , je n'ai pas la main sur les autorisations des modules IIS. Et dans la base de registre, bien que pour appid, les autorisations pour administrateur soient à "contrôle total" , le Guid de iisres.dll est en lecture seule, ce qui explique que je n'ai pas la main dans le service de composant.

    dernier point: j'ai bien le groupe  IIS_IUSRS qui est vide mais pas d'utilisateur IUSR dans l'AD.

    Je pense que tous ces points sont liés et explique la non authentification sous OWA et Activesync.

    Faut 'il un utilisateur IUSR dans l'AD et présent dans le groupe IIS_IUSRS ?

    Merci de votre aide

     

    cordialement

     

    Hugues

     

     

     

     

    dimanche 1 janvier 2012 17:11
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

     

    Nouvelles avancées.

    Je dispose d'un lab depuis aujourd'hui (2008 R2, exchange 2010), ca aide.

    IUSR : c'est réglé, il n'était tous simplement pas présent dans le groupe et je l'ai rajouté. Hélas ca ne change rien.

    les erreurs récursives venaient bien de DefaultAppPool qui contenait, en plus de la racine, /Rpc et /RpcwithCert que j'ai mis dans un autres Pool, de plus les autorisations de c:/windir/system32/inetsrv et inetsrv/config n'étaient pas correctes; il manquait les droits en lecture et exécution pour les utilisateurs.
    je n'ai plus d'erreur (application et système) mais hélas, ca ne change rien.

    La piste des service de composants est une impasse, sur le lab, les droits sont également bloqués pour les modules IIS.

    l'erreur chemin non trouvé : dans IIS > paramètres de base > de OWA est toujours là, alors que sur le Lab cette erreur n'existe pas.

    Et j'ai toujours une erreur 1314 aspnet 2.0, à l'issue d'une tentative d'authentification OWA.

    Le pire, c'est que ce lab avait un problème d'authentification OWA, page blanche et que je l'ai réglé, et OWA fonctionne.

    Malheureusement, je ne peux pas transférer ce Lab en prod.

    Le problème viendrait il de la SP2.

    Merci de vos idées et de votre aide

    cordialement

     

    Hugues

     

     

     

     

    mardi 3 janvier 2012 16:06
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    bonjour,

     

    la suite.

     

    J'avais de nouveau une erreur DCOM 10016, indiquant un problème d'accès pour un module IIS Admin, et était bloqué par le compte trusteinstaller de la base de registre; j'ai trouvé la solution et vous met en lien le site qui m'a permis d'avancer.
    http://blogs.salentica.com/rvajaria/

    il ne me reste donc plus que l'erreur aspnet 1314 sur /EWS qui semble être un problème de certificat hors EWS est sans SSL, et authentification de base.

    et l’impossibilité d'accéder à OWA, "mot de passe invalide". et bien sur, l'erreur chemin non trouvé : dans IIS > paramètres de base > tester les connections.

    j'avais dans le pool d'applications, 2 applications /owa et owa/oma, j'ai déplacé la second dans un nouveau pool, mais sans succès.

    Si vous avez des idées, merci de votre aide

     

    Cordialement

     

    Hugues

     

    mercredi 4 janvier 2012 15:48
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

     

    tout tourne autour du pool d'applications, hors en regardant de plus prêt tous les fichiers, j'ai constaté que le fichier applicationHost.config ne se mettait pas à jour des modifications faites dans IIS.

    La comparaison du fichier du Lab et de celui du serveur en cause est édifiante, il manque la moitié des répertoires virtuels.

    de plus comme c'est celui, issue des tests avec microsoft, il y a des éléments erronés.

     

    Je finis la comparaison des deux fichiers pour en remettre un correct sur le serveur.

    Mais si quelqu'un peut m'éclairer sur ce sujet.

     

    Bien cordialement

     

    Hugues

    jeudi 5 janvier 2012 11:20
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

     

    C'est désespérant et peu logique.

     

    J'ai effectué toutes les modifications pour que le fichier applicationhost.config soit correct et cela ne solutionne pas le problème.

    toujours l'erreur au niveau de IIS et impossible de se loguer en OWA. La log w3svc1 est vide de tout code erreur, a part ceux de connexion. 

    Quelqu'un connait 'il un logiciel pouvant tracer les authentifications authdiag n'existe semble t'il que pour 2003.

     

    Merci de votre aide

    cordialement

    Hugues

    jeudi 5 janvier 2012 14:08
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonsoir,

     

    la situation reste inchangée: je ne comprends pas que le fichier applicationhost.config ne se mette pas à jour alors que les fichiers web.config des répertoires virtuels se mettent correctement à jour, suivant les modifications apportées.

    Concernant les erreurs OWA, activesync et autres accès WEB à exchange, j'ai toujours une erreur à l'authentification; je précise ce détail car, après avoir mis des traces détaillées, je me suis rendu compte que j'avais un accès denied, ErrorCode 0x80070005, mais impossible de savoir sur quel répertoire ou fichier.

    J'ai vérifié et revérifié les autorisations de tous les dossiers virtuel lié à exchange et me suis assuré que les utilisateurs avaient  un droit d'accès en lecture, lecture exécution et parcours de dossier.

    J'avoue me sentir au bout des recherches et ne pas comprendre la logique de cette erreur.

    Si vous pouvez m'apporter une  quelconque piste de recherche ou idée sur ces deux sujets, elle sera la bien venue.
    - quels vérifications  faire sur les répertoires virtuels,
    - comment vérifier si tous les modules requis pour Exchange 2010 sont bien là, j'ai un doute sur web-metabase.
    - m'indiquer les droits normalement existants sur c:\windows\system32\inetsrv\  en particulier pour config.

     

    Je suis en train de remonter un autre LAB plus complet en 2008 R2 sp1 et exchange 2010 SP2 pour voir si cette config fonctionne effectivement sans problème.

     

    Merci de votre aide.

    Cordialement

     

    Hugues

     

     

     

     

    dimanche 8 janvier 2012 20:00
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonsoir Hugues,

    Tout d'abord, il faut noter que l'installation normale (ou la migration) de Exchange n'implique normalement JAMAIS de modification directe d'aucun fichier de configuration ni de Exchange, ni de IIS.

    La modification directe de paramètres, notamment dans IIS, est dangereuse par ce qu'Exchange n'étant pas au courant, ces paramètres ne sont pas sauvegardés dans AD, ni réappliqués en cas de restauration/réparation. Par ailleurs, ces paramètres deviennent parfois incompatibles avec ceux configurés au niveau d'Exchange.

    Tout cela pour dire que la meilleure solution pour revenir à une situation normale consiste souvent à désinstaller le rôle, puis à le réinstaller (notamment pour le rôle CAS).

    A noter que les répertoires virtuels /exchange et /ExchWeb ne servent pas au fonctionnement de Exchange 2010 (mais seulement pour rediriger les utilisateurs d'Exchange 2003...).

    A bientôt,

     

     

    Thierry DEMAN. Exchange MVP. https://www.mcpvirtualbusinesscard.com/VBCServer/MVPtdeman/profile (68 MCPs) http://base.faqexchange.info
    dimanche 8 janvier 2012 22:00
    |
    Modérateur
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour Thierry,

    Merci de votre réponse. J'ai bien conscience qu'il est anormal de toucher au contenu des fichiers de configurations du serveur.

     

    Je vais donc, de nouveau, désinstaller le CAS et le réinstaller.

    L'ordre correct est 'il bien suppression du CAS,  suppression de IIS réinstallation de IIS réisntallation du CAS.

    Y'a t'il une commande Powershell qui permets de vérifier que les fonctionnalités requises sont bien présentent.

     

    Merci de votre aide

    Bien cordialement

     

    Hugues de Luzy

     

     

    lundi 9 janvier 2012 08:37
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Salut,

    Oui l'ordre est déinstaller le Rôle CAS ensuite le rôle IIS

    pour refaire l'installation :

    tu commence par ajouter le IIS ensuite le CAS

     

     

    Walid

    lundi 9 janvier 2012 13:43
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonsoir,

     

    J'étais partie dans cette action mais j'ai une erreur de désintallation sur

    The following error was generated when "$error.Clear();
              $CommandAppCmd = join-path $env:SystemRoot System32\inetsrv\appcmd.exe;
              Start-SetupProcess -Name "$CommandAppCmd" -args "uninstall module exppw";
            " was run: "Échec d'exécution du processus avec le code de sortie 1168.".

     

    la, je suis vraiment coincé , ne pouvant plus ni installer ni désinstaller.

     

    Merci de votre aide

     

    Cordialement

     

    Hugues

    lundi 9 janvier 2012 16:53
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonsoir,

     

    Je réponds. Cette erreur est dû au fait que le module exppw ne se trouve pas dans les globals modules. Il faut le mettre par un inscription à la racine de IIS et un installation du module au niveau de OWA, après tout va bien.

     

    J'en profite pour donner la solution du plantage Powershell "Chemin d'accès non trouvé".

    Ceci provient du fait que dans le web.config du powershell, il est fait référence à Kerbauth, et WSMan et que c'est module ne se trouvent pas dans le applicationHost.config. Une suppression de ces deux lignes et une réinstallation de WINrm et la relance de IIS.

    Et tout est revenu dans l'ordre. Reste l'OWA.

     

    A+

    cordialement

    Hugues

    lundi 9 janvier 2012 17:55
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    correction,

     

     il ne faut pas réinstaller Winrm.

    A+

     

    Cordialement

     

    Hugues

     

     

    lundi 9 janvier 2012 18:02
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Je continue à corriger en temps réel.

    Il ne faut pas réinstaller WINrm avant d'avoir réinstaller le CAS.

    Il faut le faire après sinon Powershell se plante.

     

    Cordialement

     

    Hugues

    lundi 9 janvier 2012 18:31
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    Vous avez réussi à corriger votre problème ?

    Cordialement,

    Roxana

    Roxana PANAIT, MSFT       Join TechNetFr on Viadeo   Votez! Appel à la contribution
    Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.

    lundi 23 janvier 2012 12:58
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonjour,

    Je réponds avec un peu de retard.

    Le problème concernant les plantage de powershell est réglé. Il faut vérifier correctement l'installation du module Kerbauth en natif local sous powershell.fa

    Et éventuellement désinstaller, réinstaller winRM pour  régler un éventuelle erreur 500.

    Le problème restant est l'impossiblité de se connecter a OWA, activsync, et OAB. il provoque systèmatiquement une erreur 401.2, avec  dans la log détaillée un e erreur IIS web core Authenticate request accès refusé (0x80070005), le module apppool étant msexchangeowaapppoll. suivi, d'une erreur 401 authorization request - l'opération a réussi et un final staut 302 dans le même apppool mais sur la page owa/auth.owa

    J'ai réinstallé un nouveau serveur dans la même configuration et tout fonctionne sur celui ci.
    pour mémoire : 2008 R2 sp1 Exchange 2010 SP2.
    j'ai donc mis les deux config en parallèle et ai corrigé toutes les autorisations tant au niveau de IIS que au niveau des dossiers et fichiers.
    J'ai revérifié tous les autorisations du répertoire inetsrv dans system32, et me suis assuré que les autorisations et les propriétaire des dossiers et fichiers étaient corrects.

    mais toujours la même erreur. et le répertoire config de inetsrv ne se met pas à jour lors des modifs sur IIS en particulier l'applicationhost.config.

    J'ai sauvegardé mon exchange par "mailboxrequest" et vais restaurer les boites depuis la sauvegarde pst, après avoir recréer les comptes.

    ils faudra que je sorte et que je rentre les utilisateurs dans le domaine, avant de réinstaller les outlooks.

    Beaucoup de travail pour une erreur incompréhensible.

    Je précise que je parcours depuis plusieurs semaines les forums, pour trouver la cause de cette erreur qui est toujours liée à une erreur asp.net 1314 eventid 4007. je crois avoir fait toutes les KB de microsoft sur le sujet ;-) et ai suivi d'autres routes comme une métabase de travers, ainsi que réenregistrement de asp.net.

    Merci de votre aide.

    hugues



    mercredi 22 février 2012 13:53
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    J'ai une question complémentaire sur la metabase. Est 'elle encore utilisé sous exchange 2010 .

    dans des forums, on la met en cause dans ce type problème et on suggére :
    - Backup the Metabase
    - Stop the Msexchangesa
    - Using Metaedit delete the DS2MB key
    - Using Metaedit delete the SMTPSVC/1/domain key
    - Restart the Msexchangesa

    j'ai vu cette proposition plusieurs fois.

    quel est votre avis

    merci

    Hugues

    jeudi 23 février 2012 08:13
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    Voici les dernières nouvelles.

    J'ai du me résoudre à réinstaller le serveur. et comme prévu suite à des tests réalisés sur un serveur de test, tout fonctionne.

    le support est un vmwares esxi 5.0. et je suis de nouveau en 2008 R2 sp1 et exchange 2010 sp1. je passe en sp2 dans une semaine.

    Comme prévu aussi, la recréation des environnements utilisateurs sous outlook 2010 a été une vrai galère.
    - perte de saisie contextuelle; sous 2003 ou 2007 il était facile de restaurer le .mk2... 
    - faire une sortie entrée du domaine et donc réinstaller tout l'environnement de l'utilisateur

    la sauvegarde de l'exchange avait été faite par des export-mailboxes et la réinstallation par l'import des pst sous outlook.
    surprise, il semble ne pas tout réimporter (je dois vérifier), il manque des messages antérieurs à une date données dans les éléments envoyés.

    Voilà, Fin de l'histoire.

    Merci de l'aide que chacun m'a apporté.

    cordialement

    Hugues

    vendredi 13 avril 2012 16:23
    |