none
Agent installation fails

    Question

  • Installing the SCE agent to the Windows Server 2003 x64 (englisch with german MUI installed) I have the following problem with one of them:

    the installation fails everytime with error "The MOM Server could not execute WMI query "Select *  from Win32_Environment where NAME='PROCESSOR_ARCHITECTURE'" on computer fqdncomputername.

    Operation: Agent install

    Error Code: 80004005

    Error Description: unknown error."

    Looking to the event logs of this server I neither see "access denied" errors in security log nor any event of the agent installation.

     

    WMI is running.

    So I looked into wbemcore.log I found repeating errors:

    "GetUserDefaultLCID failed, restorting to system verion"

     

    and in FrameWork.log:

     

    "Warning! User name at exit () != user name at entry (NT-AUTORITÄT\NETZWERKDIENST) for LogRecord 08/06/2007 13:42:31.614 thread:4592 [d:\srvrtm\admin\wmi\wbem\sdk\framedyn\wbemglue.cpp.967]
    Shell Name Explorer.exe in Registry not found in process list. 08/06/2007 13:45:39.178 thread:3564 [d:\nt\admin\wmi\wbem\providers\win32provider\common\implogonuser.cpp.1019]
    Unable to locate Shell Process, Impersonation failed. 08/06/2007 13:45:39.213 thread:3564 [d:\nt\admin\wmi\wbem\providers\win32provider\common\implogonuser.cpp.1027]"

     

    What is the problem with this server?

    Monday, August 06, 2007 1:03 PM

Answers

  • Hi,

     

    none of the ways to repair WMI solved the problem: something prevents WMI to read the most (existing) instances of Win32_Environment.

    But I found a way to get around this: I created a new REG_SZ value PROCESSOR_ARCHITECTURE under HKCU\Environment identical with the one under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.

    Pushing the agent succeed.

    Tuesday, October 09, 2007 2:51 PM
  • Hi Peter,

     

    Thanks for your update. The picture shots implies some errors with WMI on the client. Please try following steps:


    1. Log on the problematic client and go to Control Panel >> Add/Remove Program >> Click Add/Remove Windows Components.


    2. Select Management and Monitoring Tools and Click Details.


    3. Check WMI Windows Installer Provider and Click OK.


    4. Click Next to proceed the installation.


    5. Reboot the system to commit the changes.

     

    6. Uninstall the agent on the problematic client and try re-pushing the SCE agent from SCE to see if works.

     

    More information about the WMI, please refer to MSDN newsgroup:

     

    http://msdn.microsoft.com/newsgroups/

     

     

    ---------------------

    Regards,

    Jie-Feng Ren

    Microsoft Online Community Support

     

    Tuesday, August 14, 2007 1:46 PM

All replies

  •  

    The error code implies that the account used to install the agent was denied access to WMI.  Could you try running the SCE agent install using the MACHINE\Administrator account (by selecting the optional setting to provide specific credentials and using the check box for the local administrative account)?
    Monday, August 06, 2007 5:38 PM
  • With the local administrator account I got the same error.

     

    Today I additional got in SCE console an error related to this server "Unable to connect to WMI on Remote Computer".

    Tuesday, August 07, 2007 10:24 AM
  • Can you check that rsop.msc reports the exceptions for the windows firewall remote administration have successfully applied to the machine?  Is the IP still accurate for the SCE server?  Is WMI running on the remote machine?

     

    If all of these are true, can you try running a manual agent install using the SCE installation bootstrapper option for agent?  The Management group name value will be format [SCE Server Name]_MG.

    Tuesday, August 07, 2007 6:18 PM
  • Hi Peter,

     

    The error message prompt implies something wrong with permissions. Before pushing the agent to clients, please ensure the following points:

     

    1. Use domain\administrator account to push agent.

     

    2. Please make sure the port  TCP 5732 on the SCE Server computer and the port TCP 139, TCP 445, UDP 137, UDP 138 on the client computer has been opened.

     

    3. Please ensure the GPO (SCE managed computers, SCE all computers) have been applied.

     

    4. Stop firewall service to try it.

     

    If the problem still exists, try to  install agent manually to see if it works. Regarding how to install agent manually, please refer to following article:

     

    http://technet.microsoft.com/en-us/library/bb437257.aspx  

     

    Hope it helps.

     

    ---------------------

    Regards,

    Jie-Feng Ren

    Microsoft Online Community Support

     

    Wednesday, August 08, 2007 10:01 AM
  • Thanks for all the hints.

    So I approved that
    - WMI is running
    - SCE GPOs are applied to the system
    - no firewall blocks the SCE ports on the system or the SCE server
    - I use the local or the domain admin account instead of SCE action account to push the agent.
    But the behaviour of the agent installation didn't change.

    So I installed the agent manually as described in the Technet article what was working without any error but brings 2 new problems to me:
    1. after approving the agent in SCE the system is showed in SCE Console as "healthy" but is greyed out (as shutdown) although it is running permanent
    2. because we are using Remote Operations Manager Scenario: who to get the system into the Remote Operations Manager (SCOM 2007) when discovering and installing it from Console doesn't work?


    What I realized in meantime is:
    - using the Scriptomatic2 tool and query the Win32_Enviroment class of CimV2 namespace I was able to get the object "PROCESSOR_ARCHITECTURE"
    - using the Wbemtest tool and do the query posted in the error message there was no match (on other systems there was a corresponding to that seen with Scriptomatic).

     

    Wednesday, August 08, 2007 4:38 PM
  • Hi Peter,

    I would like provide some suggestion as follows:

     

    1. Run “services.msc” command and check OpsMgr Health Service is log on as local system account on that problematical client.

     

    2. Since the SCE agent is installed manually, the SSL and Code Signing certificates must be copied from the c:\program files\system center essentials 2007\certificates folder directory on the Essentials server to the c:\program files\system center essentials 2007\certificates folder directory on the client.

     

    3. The WSUSSSLCert.cer should be imported into the local computer's trusted root authority store. The WSUSCodeSigningCert.cer should be imported into the local computer's trusted root authority, trusted publishers and third party root certification authority stores.

     

    4. After that, run “wuauclt \detectnow” on the problematical to see if it works.

    When using a remote operation manager, the computer must be configured with the SSL and Coding Signing certificates that are used on the SCE 2007.

     

    If the problem still exists, please help us to collect following information:.

     

    More information:

    Please refer to the following article to generate Network Edition (Mpsrpt_network.exe)\Software Update Services Edition (Mpsrpt_sus.exe)\Alliance Edition (Mpsrpt_alliance.exe)\Setup Edition (Mpsrpt_setupperf.exe)\Directory Service Edition (MPSRPT_DirSvc.EXE) of MPS report for further analysis.

     

    818742.KB.EN-US Overview of the Microsoft Configuration Capture Utility (MPS_REPORTS)

    http://support.microsoft.com/default.aspx?scid=KB;EN-US;818742

     

    You can send the files to us via SCEDATA@microsoft.com.

     

    Note:

     

    Please include the following three lines in the email body:

     

    Agent installation

    http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1967838&SiteID=17%20

    Jie-Feng Ren - MSFT

     

    Regarding more information about how to send email to SCEDATA@microsoft.com, please refer to:

     

    How to send files to the Microsoft SCE team for review

    http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1680389&SiteID=17

     

    Post a quick note in the current thread after sending the email.

     

    Thanks!

     

    ---------------------

    Regards,

    Jie-Feng Ren

    Microsoft Online Community Support

     

     

    Thursday, August 09, 2007 12:44 PM
  • Hi Jie-Feng,

     

    because working through the 4 points didn't solve the problems,  I produced the requested MPS Reports and send it out to you.

    Thanks for your help!

    Sunday, August 12, 2007 7:46 PM
  •  

    Hi peter,

     

    Thanks for your update. Analyzing the MPS, I would like to suggest try following steps:

     

    1. Please ensure the system time of the target computer and the SCE server are synchronized (please also check the time zone).

     

    2. Restart OpsMgr health service on the SCE server and target client.

     

    3. Log on the SCE server as domain\administrator account, run “eventvwr” command to open event viewer. Click the “Action” and choose “connect to another computer”. In the pop up window, type the targeted computer <computername> to see if can contact it.

     

    4. After that, please see if it works.

     

    If the problem still exists, please help us to collect following information:

     

    1. Could you try the following and let me know the result:


    1). Log on to the SCE server with the domain\administrator account
    2). Start – run – wbemtest.exe
    3). Click on Connect
    4). In the Namespace box, enter
    \\<computername>\root\cimv2 and click on Connect, where the computername here is the target computer’s name.
    5). Click on Query
    6). In the query box, enter “Select * from Win32_OperatingSystem” and click on Apply.

     

    2. Generate Alliance Edition (Mpsrpt_alliance.exe) of MPS report on SCE server as well.

     

    3. If possible, please capture the screen shots of the error prompt when pushing agent.

     

    Please collect the information mentioned above and send them to scedata@microsoft.com.

     

    Monday, August 13, 2007 11:44 AM
  • Hi Peter,

     

    Thanks for your update. The picture shots implies some errors with WMI on the client. Please try following steps:


    1. Log on the problematic client and go to Control Panel >> Add/Remove Program >> Click Add/Remove Windows Components.


    2. Select Management and Monitoring Tools and Click Details.


    3. Check WMI Windows Installer Provider and Click OK.


    4. Click Next to proceed the installation.


    5. Reboot the system to commit the changes.

     

    6. Uninstall the agent on the problematic client and try re-pushing the SCE agent from SCE to see if works.

     

    More information about the WMI, please refer to MSDN newsgroup:

     

    http://msdn.microsoft.com/newsgroups/

     

     

    ---------------------

    Regards,

    Jie-Feng Ren

    Microsoft Online Community Support

     

    Tuesday, August 14, 2007 1:46 PM
  • Hi,

     

    none of the ways to repair WMI solved the problem: something prevents WMI to read the most (existing) instances of Win32_Environment.

    But I found a way to get around this: I created a new REG_SZ value PROCESSOR_ARCHITECTURE under HKCU\Environment identical with the one under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.

    Pushing the agent succeed.

    Tuesday, October 09, 2007 2:51 PM
  • Hi Peter,

     

    Thanks for your update. I appreciate that you share your experience here, and I believe that it will help other community members in the future.

     

    Wednesday, October 10, 2007 5:49 AM
  • I had the same issue and the same workaround fixed the problem. Thanks!

     

    Monday, October 15, 2007 9:33 PM
  •  

    Hello Peter,

     

    I am having the same problem.  Where did you add this entry?  I was not able to find the entry in the registry.

    Tuesday, October 16, 2007 1:10 PM
  •  

    Hello Yasser,

     

    I am having the same problem.  Where and how did you add the entry? 

    Tuesday, October 16, 2007 1:22 PM
  • Hello,

     

    Logon with administrative privileges to the affected machine, start REGEDIT, create a new REG_SZ value PROCESSOR_ARCHITECTURE at HKEY_Current_User\Environment identically the existing one at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.

    Tuesday, October 16, 2007 2:18 PM
  • Peter,

     

    Thanks for the info.  Once the registry entry is added, does it require a reboot of the problem server?

     

    Thanks

     

    Tuesday, October 16, 2007 3:05 PM
  • Hello c4lxxx,

     

    it works without a reboot.

    Tuesday, October 16, 2007 6:43 PM
  •  

    I was hoping you would say it needed a reboot, because it didn't work for me.
    Tuesday, October 16, 2007 7:44 PM
  • Hello c4lxxx,

     

    I had the same problems with WMI :

     

    - acces denied for "select * from Win32_Environment"

    - wbemcore.log  - GetUserDefaultLCID failed, restorting to system verion

    - framework.log  - Unable to locate Shell Process, Impersonation failed

     

    After I granted NETWORK SERVICE (SERVICE) account with "launch and activation permissions", I have no problems with access denied error, but the messages still persist in logs.

     

    DCOMCNFG -> My Computer -> Properties -> COM security -> L&A permissions -> Edit Limits

     

    I don't think that it is completely right decision, but it helps.

     

    Regards,

    Zenger Sergey

     

     

     

    Thursday, October 18, 2007 1:19 PM
  • $5 says your server's PATH environment variable is greater than 1023 characters.

     

    Thursday, February 07, 2008 11:26 PM
  • was struggling on this error since one week.. NO SOLUTIONS anywhere...
    your suggestion of creating the reg key resolved it instantly..

    Thanks a lot man!!!!!

    Tuesday, March 04, 2008 8:46 PM
  • PLEASE remember that creating the registry entry for the processor architecture is just a band-aid for the entire Win32_Environment provider failing!  You might be able to get past the initial install, but you're likely to see issues later down the road.  The root cause of this problem is that MS increased the max path from 1023 characters (+1 control character) to 2048 chars total.  Unfortunately, they forgot to update WMI when they did this.

     

    If your server's system path variable (not your user path variable) is longer than 1023 characters, you'll see the problem.  The best workaround is to shorten the path by modifying it to use 8.3 file name syntax instead of long file names (use dir /x to see short file names).  No reboot required, no services to restart.  This issue has been resolved in Windows Server 2008.  I'm currently pushing Microsoft to backport the fix to 2003, but no promises yet.

     

    Here is code to reproduce the problem at will (sorry about the line wrapping).  That emoticon should actually be ": S" without a space.

     

     

    Set WshShell = WScript.CreateObject("WScript.Shell")
    Found=False
    strComputer="localhost"
    SavePath="save your current path here"

    '**********************************************************************************************
    ' Break it
    '**********************************************************************************************

     const HKEY_LOCAL_MACHINE = &H80000002
     ' Clear used vars
     oReg = ""
     ' Fetch WMI registry objects
     Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\defaultTongue TiedtdRegProv")
     strKeyPath = "SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
     strValueName = "Path"
     oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,PathValue
     wscript.echo "Path was: " & len(PathValue) & " bytes"
     
     while len(PathValue)<1024
      PathValue=PathValue & ";" & PathValue
     wend
     oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,PathValue
     oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,PathValue
     wscript.echo "Path is now: " & len(PathValue) & " bytes"

    Set objWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
    Set colWMIQuery = objWMI.ExecQuery ("Select * from Win32_Environment where NAME = 'PROCESSOR_ARCHITECTURE'")
    For each objProc in colWMIQuery
     Found=True
    Next
    Set colWMIQuery=Nothing
    Set objWMI=Nothing

    If Found then
     wscript.echo "Win32_Environment is working" & vbCRLF
    Else
     wscript.echo "Win32_Environment is NOT working" & vbCRLF
    End If


    '**********************************************************************************************
    ' Fix it
    '**********************************************************************************************


    oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,SavePath
    oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,PathValue
    wscript.echo "Path restored to: " & len(PathValue) & " bytes"

    Set objWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
    Set colWMIQuery = objWMI.ExecQuery ("Select * from Win32_Environment where NAME = 'PROCESSOR_ARCHITECTURE'")
    For each objProc in colWMIQuery
     Found=True
    Next
    Set colWMIQuery=Nothing
    Set objWMI=Nothing

    If Found then
     wscript.echo "Win32_Environment is working"
    Else
     wscript.echo "Win32_Environment is NOT working"
    End If

    Tuesday, March 04, 2008 9:02 PM
  • Guys

     

    I have this issue on 50% of my citrix servers when approving the scom agent upgdate after sp1 deployment. The other 50% updated succesfully as did all of the other server agents.

     

    Is there any further sign of a proper resolution to this ?  I have tried the regkey workaround and also verified that the path is <1023 characters.

     

    Regards

     

    Mark

    Tuesday, March 18, 2008 10:22 AM
  • FYI, the fix for the long path has finally been back-ported from Server 2008 to Server 2003.  Here is the KB article; you'll need to call Microsoft to get the fix.

     

    http://support.microsoft.com/kb/950681

     

     

    Thursday, April 10, 2008 6:39 PM
  •  

    Were you able to find a solution to this problem? I have this problem consistently with most of our Citrix Servers, My path is considerable less than 1024... I also tried the registry fix to no avail.

     

     Using WBEMTEST on my local machine and connecting remotely to One of the Failing Citrix Servers I query "select * from win32_environment" ... and it takes about 6 minutes to give the answer.

    Monday, October 13, 2008 8:16 PM
  • Have you tested the hotfix http://support.microsoft.com/kb/950681 ?

     

    Tuesday, October 14, 2008 7:45 AM
  • Thanks for the response.

     

    1.) I have not tested the hotfix yet, I do intend to, ... I have about 98 Citrix servers... about 10 are test... they all will install without a problem. 5 of the Production Citrix servers installs with no problem, the other 83 Fail all with the same error. (I have about 1,100 other various Windows Servers that worked fine). I have to do a change control and work with our server support group to install the hotfix... working on trying that BUT.... I cannot attempt this until Friday night.

     

    2.) I am skeptical of the Hotfix being the answer because::

    a.) Only my Citrix Servers are affected.

    b.) Adding the registry key does not help

    c.) The path variable on all of these machines is not anywhere near 1,023 (I wrote a script to test the path variable on all of them, some are as hight as 609, some much less)

    d.) When I run the query using WBEMTEST (select * from Win32_Environment)

    - When run local it works fine

    - When run remote, it appears to fail (no response), but it actually will complete if you wait about 6 minutes

     

    Tuesday, October 14, 2008 12:29 PM
  •  

    - One of the Server guys was able to install the hotfix on a server today, there was no change.

     

    - We were able to discern that ALL of the Citrix servers are slow to return a remote query for:

                 --- "select * from win32_environment"

                 --- "select * from win32_NetworkLoginProfile"

        Wasn't just the ones that failed.... The ones that were successful were just a little faster (less than 3 minutes)...

     (I was told that the timeout in the SCOM agent install is 180 seconds).

    Tuesday, October 14, 2008 7:26 PM
  • Hi Peter,
                 It Works for me

    Thanks
    Upendra D
    Thursday, August 27, 2009 10:07 AM
  • Thanks, this post helped me much
    Wednesday, May 18, 2011 2:12 PM
  • Nice one...Thx

    John Bradshaw

    Wednesday, June 08, 2011 10:17 PM
  • If I may add something that helped me, hopefully it will save someone else the pain.

    I spent about a week trying to troubleshoot that SCOM Agent Install error, I eventually found out about the "Select *  from Win32_Environment where NAME='PROCESSOR_ARCHITECTURE'" error and tried adding registry keys to no avail. I could run that statement locally on the troubled server and get a fairly quick response. Running it remotely it took about 3 minutes to return the values. Note that it didn't fail, it was just slow..slow enough for SCOM to give up attempting to install the agent.

    So after epic digging/monitoring running the query remotely via wbemtest and kicking off procmon showed it was opening and closing HKCU keys over and over and over. Turns out the UPHC (User Profile Hive Cleanup) service was installed (by someone, somewhere at sometime, for some reason..), I stopped it and the install went through perfectly.

    Hope it helps someone!

    Peace,

    -Dan

    Thursday, March 15, 2012 4:43 AM