Hi,I've just manually installed an Ops Mgr 2007 R2 x64 agent onto a 64-bit Windows Server 2008 SP2 domain controller. A 32-bit MOM 2005 SP1 agent was already installed on this server along with the AD MP Helper Object component. Pretty soon after I started getting errors on the Ops Mgr 2007 R2 server along the lines of "ActiveX component cannot instantiate object" etc. so I the installed the 64-bit AD Helper Object from the R2 media. This stopped the errors on Ops Mgr 2007 R2 but started them on MOM 2005.I'd read that there were issues with this object when 64-bit agents were installed alongside 32-bit MOM 2005 agents (KB956184) however these were supposed to have been fixed in R2 (KB971410). Did I install something in the wrong order?Any advice would be much appreciated. Thanks!

I have no specific experience on this, I'd start checking how many oomads.dll are installed in your system, from what I understand you should have two of them one for 32 bits and the other for 64 bits. If this is not the case try to reinstall the MOM 2005 helper objects and then the R2 helper objects.- Daniele, Microsoft MVP OpsMgr This posting is provided "AS IS" with no warranties, and confers no rights. http://nocentdocent.wordpress.com http://www.progel.it

i think the AD mp still has this issue. in fact when you look at the oomads install function used in the AD mp, i think there's a check for this situation and won't install the helper on 64bit if there's a 32 bit helper already. So maybe the "fix" was to stop the install of oomads 64bit when the 32bit version is installed already.But i haven't really checked the function in detail. http://jama00.wordpress.com/2010/01/26/monitoring-multiple-active-directory-forests-without-a-trust/ i've made a blog about AD mp. It probably doesn't concern you, but it gives the location of the installoomads function and why you don't need to install manually :) Rob Korving http://jama00.wordpress.com/

Rob, if this is the case you won't be able to monitor DCs and this is the limitation we had since OpsMgr RTM, no side by side on 64 bits DCs. But now that I'm making up my mind, why do you need a 32 bit MOM 2005 agent on your DCs? Why don't install the 64bit version? There are certain incompatibilities in side by side not related to bits but to MP, for example no side by side for Exchange 2003 MPs, and if I can remember right, some issue with the AD mp with replication monitoring.Alas I don't have a mock environment with MOM 2005 anymore.- Daniele, Microsoft MVP OpsMgr This posting is provided "AS IS" with no warranties, and confers no rights. http://nocentdocent.wordpress.com http://www.progel.it

really, This is what it says in the installoomads routine: scriptAPI.LogScriptEvent EventSource, EVENT_ID_INSTALL_OOMADS_FAILURE, EventSeverityWarning, "This upgrade is not supported. Can not install OOMADS 64 bit version as there is already a 32 bit version of OOMADS installed"But i have to say i don't really understand how they come to this conclusion. I can see they check for installstate by some product guid and then check if the helper dll exist in a certain location. If it exist, the above error gets logged and the function is exited. i don't see where they check for architecture, but this might be something hidden in the hardcoded productguid or hidden in the installpath. To know for sure, i would need to test it a bit further.For now this is my stance on running mom2005 and scom2007 together, which should be only a temporary situation imho. While mom2005 is leading you shouldn't install the 64 bit helper and when scom becomes leading you should install it manually.Rob Korving http://jama00.wordpress.com/

You cannot run both MOM2005 and SCOM2007 agents on DC without issues and conflicts, I ran into this in our environment during MOM to SCOM migration. You must run one or the other to get reliable monitoring, on all other NON DC servers there werer not issues except when it comes to x64 and the AD Helper Object. (There was no x64 agent install and no x64 AD Helper object that I remember with MOM2005. So if you upgrade or migrate your servers to x64, it's better you remove the MOM2005 agent and not use it and install the SCOM x64 agent instead, but before you do read my notes below.) Make sure when you migrate to SCOM you do the following: 1.) Completely remove the MOM 2005 agent by *FIRST removing the AD Helper Object *FIRST **before** uninstalling the MOM 2005 agent and **prior to installing the SCOM agent. This MUST be done MANUALLY, unfortunately, as the agent uninstall through the Console DOES NOT remove the current existing AD Object Helper in MOM2005. ** If you do not do this and you remove the MOM2005 Agent First without uninstalling the AD Object Helper, you WILL NOT be able to remove the AD object Helper that was loaded with the MOM2005 agent. If you find yourself in this situtation, there are two ways to removing the old AD helper object. a.) Reinstall the MOM2005 agent, then uninstall the AD helper Object, then remove the agent. b.) Microsoft Support provides a custom uninstall tool that can remove the AD helper object without the agent present, it is called the "Windows installer cleanup utility" and you can find it at: http://download.microsoft.com/download/e/9/d/e9d80355-7ab4-45b8-80e8-983a48d5e1bd/msicuu2.exe . This tools actually uninstalls any Microsoft bits found on the server. 2.) Once you have manually removed the MOM2005 32bit agent off all your DC, then install the SCOM agent through the console to the DC. I do not recall if the SCOM console push also installs the AD helper object, but if it doesn't, you can manually install it after the fact. 3.) Make sure you use SCOM x32 versus x64 bit installs per platform X. Put x32 agent on x32 systems and x64 agent on x64 systems. If you do not you will run into issues with perf collections as there are x32 and x64 bit perf libraries. I still ran into issues on x64 systems that ran x32 applications, because a x64 SCOM agent is wanting to use only x64 perf libs and if there are only x32 perf libs available because the applications is x32, then you will have to talk to MS Support as I do not think there is any way to address this issue. George Maloy SCOM engineer and consultant