10.2.0.4 Agent Pull Technique Upgrade

We have recently upgraded the Grid Control OMS to 10.2.0.4 from 10.2.0.3 running on AIX. I would like to upgrade the management agents utilizing the "pull" technique identified in the README for the 10.2.0.4 patch (3731593). However, the instructions indicate configuring the patch setup by supplying the Oracle Metalink credentials, creating a job to refreshfrommetalink and executing, etc. We have an issue because we are inside an isolated network without outside access.
Can I utilize the "pull" method to achieve the upgrading the management agents to 10.2.0.4 without Metalink?
Thanks!

No the last step in the job is 60 minute timeout waitforAgent event.
then a connection refused.
The log steps from GC:
E:\oracle\product\agent10g\sysman\config\emd.properties
E:\oracle\product\agent10g\sysman\config\emd.properties
oms host = http://oem.ad.dot.gov
oms port = 4889
E:\oracle\product\agent10g\EMStagedPatches\3731596\3731596\AgentPatchDownload10.2.0.4.0
appDir is created
E:\oracle\product\agent10g\EMStagedPatches\3731596\3731596
E:\oracle\product\agent10g\EMStagedPatches\3731596\3731596\AgentPatchDownload10.2.0.4.0
ORACLE_HOME = E:\oracle\product\agent10g
baseDir = E:\oracle\product
cmd is:WGET.exe http://oem.ad.dot.gov:4889/agent_download/patchset/10.2.0.4.0/win32/response/patchset.rsp
From the steps in the GUI:
Here is some more output from the GUI:
Running: E:\oracle\product\agent10g/sysman/admin/scripts/osm/ecmPatchDatabase.pl
Argument count: 15
Perl version: 5.008003
Hostname: osthqnwdb010
Operating system: MSWin32
Time: Mon Aug 11 12:22:27 2008
Use of uninitialized value in scalar assignment at
E:\oracle\product\agent10g/sysman/admin/scripts/osm/ecmPatchDatabase.pl line
1770.
Use of uninitialized value in scalar assignment at E:\oracle\product\agent10g/sysman/admin/scripts/osm/ecmPatchDatabase.pl line
1770.
Applying Patch 3731596...
start /b E:\oracle\product\agent10g\perl\5.8.3\bin\MSWin32-x86-multi-thread\perl.exe -w
E:/oracle/product/agent10g/EMStagedPatches/3731596/3731596/emdpatch.pl 3731596
E:\oracle\product\agent10g\EMStagedPatches\3731596\applyPatch_3731596.log 2>&1
applyPatch 3731596 successful
Suspend step timeout exceeded.
(60 minutes)
==============================

Similar Messages

Upgrade - Do I need to uninstall peoplesoft agent plugin before upgrading it?

Hi Guys,
I am performing an upgrade of PSEM plugin from 8.51 to 8.52 in Grid Control 11gR1.Do I need to uninstall peoplesoft agent plugin before upgrading it?

I ended up using the live chat to get the question answered earlier today - but thank you for your response - and you're correct.
As for the creative cloud version - no, I opted not to get that. I hope I don't live to regret it,
but I'm not in a marketing/design program/etc. I just need photo editing for some end-of-year projects for school that needed better than average photo quality.
Thanks for taking the time to respond - much appreciated!

OUI-10133 - silent install via agent pull

For an agent pull on AIX, the agentDownload.aix successfully pulls the agent files, unzips, and than gives this OUI-10133 about invalid staging. Since it is the one doing the "staging" and download, it doesn't quite make sense to me, unless the binaries it downloads that are staged are bad. any other ideas.
any ideas?

Please follow the instruction.txt and try again

Zen Agent 11.3 upgrade issue

Hi All,
So I just successfully migrated my entire company that I work for from a single ZCM11.2 Primary, to 2 ZCM11.3 Virtual Appliances and a remote sybase database server. Was fun, but now im trying to update all of our existing machines Zenworks Agents to 11.3, most of them upgraded and moved to successful status in the deployment history, but some just stay in pending even though the agent has indeed been upgraded. Those machines already have been rebooted and verified that it installed correctly. These machines are keeping this system update Deployment from baselining. How do i manually change their status to Successful?
Thanks all!

I have what sounds like this same problem. At the moment, 880 out of roughly 4300 computers are sitting in "Pending" status, even though the overwhelming majority of them were actually installed from scratch with the Agent version which is due to be deployed. (We install the Agent on the image, for what that may matter.)
One thing I've noticed is that although the System Update in question lists those computers as Pending, and the same System Update is listed in the "Assigned System Updates" pane in the workstation objects for those computers, if I go to primaryserver/zenworks-systemupdate/, select "Test service", select the "getAssignedSystemUpdates" option, and enter the GUID from one of those computers, it lists no system updates as available.
I've noticed that behavior both for computers which have the new Agent already, and for ones which still have an older one. In the cases of computers which have an older one, if I enter the system's GUID and the appropriate system-update GUID into the "setDeviceUpdateStatus" form, the System Update then shows up under getAssignedSystemUpdates and the computer initiates the update normally. (However, even assuming it would be safe - see below - doing this with 880 computers would not be practical.)
I have not tried doing this with one of the computers which already has the new Agent, because I don't know what trying to deploy a System Update that's already installed might do, and I don't have a test case (exhibiting the symptoms) which I know I can safely risk.
We recently reimaged a large number of computers, and I noticed that at that point the number of systems with Pending status went down significantly - it used to be well over 1000, I think by a good few hundred. I don't know what bearing this might have on matters, but it seemed worth mentioning.
Any ideas of anything I could try here?
Just for the record, this is with ZENworks 11.2.2. We're looking at deploying 11.2.4 or possibly 11.3 within the next couple of months, but I'd like to get 11.2.2 officially Baselined before doing that, and that requires clearing up these hundreds of computers which are showing Pending status.

UCCX RECORDING STOP WORKING AFTER AGENT´S PC UPGRADE FROM XP TO WINDOWS 7

Dears, We have a customer with UCCX 8.0(2) already working, some agents upgrade per company policy theirs PC´s to Windows 7, After that, supervisor are unable to monitoring/recording the upgrade agent´s PCs.
We installed Ethereal in those PCs and see that the Agent PC did not generate the "copy" RTP packet to Supervisor desktop, as in XP machines where you can see both packet, from phone to phone, and from agent´s PC to supervisor´s PC.
We disable antivirus software and Windows firewall and make everything in troubleshooting documentation, even the registry setting changes.
We did not change hardware, only OS.
We are running Windows 7 Enterprisse edition.
Does anybody stuck with this problem?
Regards
Gustavo Chiarelli

If you are sure that Postinstall is pointing to the right NIC (IP address for which you see G.711 packets when you run NICQ.exe), that’s good. But most of the times, I see problems like this or Span to PC port problem.
I think you can have a look on this doc https://supportforums.cisco.com/docs/DOC-13223 before requesting again to get response from TAC.

Agent cannot be upgraded

Hi !!
I've used patch 6810189 to upgrade database (OS : windows server 2003 SP2 ) 10.2.0.1 to 10.2.0.4.
Database version and Enterprise Manager are both upgraded successfully . But when I run ' emctl agent status ' to check agent version , it shows that agent version is 10.1.0.6 .
Besides , when I check on Oracle Universal Installer ---> Installed Products .There are 2 parts :
+ Oracle database 10g 10.2.0.1
+ Oracle Database 10g Release 2 Path Set 3 10.2.0.4
While I was upgrading Database and Enterprise Manager , no error occured
I don't know what I'll have to do to upgrade Agent version .
Can you give me some advices ?
Thanks

Tien Lai wrote:
Hi !!
I've used patch 6810189 to upgrade database (OS : windows server 2003 SP2 ) 10.2.0.1 to 10.2.0.4.
Database version and Enterprise Manager are both upgraded successfully . But when I run ' emctl agent status ' to check agent version , it shows that agent version is 10.1.0.6 .
Besides , when I check on Oracle Universal Installer ---> Installed Products .There are 2 parts :
+ Oracle database 10g 10.2.0.1
+ Oracle Database 10g Release 2 Path Set 3 10.2.0.4
While I was upgrading Database and Enterprise Manager , no error occured
I don't know what I'll have to do to upgrade Agent version .
Can you give me some advices ?
ThanksYour upgrade was an overall upgrade of the database. That does not mean that every component was (or needed to be) upgraded. Each component will report it's own level.

Cannot restart CCMS agent after kernel upgrade

Morning,
Can someone help with my issue? I've just upgraded my Business Intelligent Development system to Kernel 700 - Support package 200.
Since the change I'm unable to restart our CCMS agent on the server. When I try to restart get the following message appear "ERROR: Cannot open Monitoring Segment 0 rtc = 255".
I've tried to uninstall and re-register the agent, unfortunately still getting the above message.
Many Thanks
Gavin

Gavin
check SAP Note 1307195
INFO: Download Agent Alerts and some current values to
/usr/sap/QO1/DVEBMGS00/log/ALAGENTALERTS.
INFO: Disconnected from monitoring segment, reconnecting now ...
ERROR: Cannot open Monitoring Segment 0 rtc = 255
Last reported error: [255] AlAttachShm: ShmAlCreate (SHM_ATTACH)
returns error 1.
The problem was resolved in CCMS Patch Collection 2009/1. See the referenced note for the information about patch availability and agent upgrade procedure.
As a workaround use monitoring and restart tools your operation system provides to automatically restart the agent process. For example, you can use inittab configuration file as described in the on-line documentation:
http://help.sap.com/saphelp_nw70/helpdata/EN/43/041c1d0fcf2bc4e10000000a114cbd/frameset.htm
Nesimi

Oem agent pull or push?

Hi all,
what is the difference between pushing the agent to the target from oms and pulling the agent from target to oms?
what are the pros and crons?
thanks
andrew

Assuming this question relates to agent installation, you don't say, the issue is merely one of where the installation files are located and where it is most convenient for me to work while performing the installation.

AGENT steps for Upgrading a database to new release

I have a 9.2.0.6 database that needs upgrading to 9.2.0.7. The OMA is 10.2.0.2. Are there any special steps required in the upgrade to the database and listener for the OMA? The ORACLE_HOME and TNS_ADMIN will be changing to reflect the new software. I know that the $AGENT_HOME/sysman/emd/targets.xml has references to the oracle db version.

Install base release, Install patchset, Install
one-off's required.
${ORACLE_BASE}/product/9.2.0.7OK. How cost effective is it to go through all that for every Server and Database in an organisation? BTW. How many Servers and Databases do you have in your Organisation?
The install can occur at anytime while the system is
up, So all that is needed is the migration of the
database from the ${ORACLE_BASE}/product/9.2.0.6 home
to the new home - and one-offs. Again, how do you measure this in terms of cost (resource, Infrastrucure, Time, money to do)? I will do this only if there is requirement for Parallel run of both(e.g. for an environment supporting both component releases). Else, all I need is backup 9206 server and databases to backup media and upgrade to 9207.
This greatly reduces our downtime and provides fall back if necessary.The difference in down time here is the time you will use to run the installer for binaries (whch takes the least amount of time). You still need the downtime to copy and upgrade the database after you have gone through that long process. And depending on the number of patchsets, CPUs, one-offs that has been applied to 9206, you are spending hours upgrading from 9206 to 9207.
I am concerned that a simple "Component Release" upgrade will require a lot of resource, Infrastrucure, Time, money to do. What will you do if you are managing databases for 10 different projects made up of 50 Oracle Server Installations, each with 4 Database Environments (Dev, SysTest, CAT and Prod = 200 Databases) and on four different platforms with some housing Terabytes of data. Personally, the process you go through for a Component Release will cost me unnecessary thousands of pounds. So, I will do what you do for only Major Release (e.g 9.2 to 10.1). If it is "really" necessary, I will do it for a Maintenance Release (9.1 to 9.2), but not a Component Release (9.2.0.6 to 9.2.0.7)

Upgrd UCCX- from 7.01 to 7.02- some agents cant get through CAD upgrade

A few days ago we upgrded our UCCX and some agents can not upgrade the CAD or CSD. Most of those that can't I had then completely uninstall all CAD and CSD on thier machine, then provided them with the new version .. most are successful with this method.
however I am having a few that are getting a pop up error that states : License error has occurred, try agin in 5 minutes ...' Then getting another window that states that the License Server is down'.
I checked the Services and all CCX services are running
I checked the Control Center and the Status is "In_Service"
We have not exceeded our number of configured agents and not exceeded out number of agents logged in.
any suggestions ??

thanks, does either the restart of the Cisco Desktop License Manager Service or the Directry Resync cause any disruption to calls or agents..... will anyone even know that this action was taken ? (if so I have to wait until very late night or early morning ....

ISE nac Agent automatic upgrade possible ?

Hello all,
I have this :
802.1x windows with NacAgent version (let's say 1) <----> 802.1x Enabled Switch (aaa radius OK) <------> ISE and AD on the same LAN
ISE is configured for client provisionning with material (NacAgent version 2) downloaded from Cisco website (as depicted in the documentation)
I've a basic authentication and authorization scheme that let me in properly but I expect the NACAgent to be upgraded.
No profiling is configured for the time being.
Is anybody can help ?
Best regards ?

Hi Tarik,
Your are right regarding that option "upgrade is mandatory"
However, my case was that you do need to enter the ISE's FQDN on the NAC Client and make sure that DNS operates properly.
Once authenticated, the NAC agent shows an upgrade message.
It works.
Thank you all.

EM12cR2 - how to clean up old agent core directories after upgrade?

Running EM12cR2+PSU1 on Linux x86-64.
Does anybody know the recommended/supported/correct way to remove old versions of the EM12c agent core directories on managed servers after the agents have been upgraded to EM12cR2? This isn't a huge issue, but I've been setting up my agents on small (2GB) dedicated volumes and I won't have enough space available for the next round of upgrades unless I get the old stuff cleared out.
I have one server that was added to the environment after my EM12cR2 upgrade, and several servers that were already being monitored before the upgrade. The servers where I upgraded the agents after installing EM12cR2 all still have copies of the agent base core/12.1.0.1.0 directory along with the new agent base core/12.1.0.2.0 directory. I've tried removing this directory and bouncing the agent, but the agent gets blocked since it apparently cannot locate some files it expects to find. Other than being rejected by the OMS, the agent appears to function fine. I can only unblock the agent successfully if I put the 12.1.0.1.0 directory back in place.
Here's what I'm seeing on an upgraded agent:
/oraagent> du -sh agent12c
1.5G    agent12c
/oraagent> ls agent12c/core
12.1.0.1.0 12.1.0.2.0
/oraagent> du -sh agent12c/core/*
626M    agent12c/core/12.1.0.1.0
534M    agent12c/core/12.1.0.2.0
/oraagent> emctl status agent
Oracle Enterprise Manager Cloud Control 12c Release 2
Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved.
Agent Version     : 12.1.0.2.0
OMS Version       : 12.1.0.2.0
Protocol Version : 12.1.0.1.0
Agent Home        : /oraagent/agent12c/agent_inst
Agent Binaries    : /oraagent/agent12c/core/12.1.0.2.0On a host that never had the EM12cR1 agent installed, I see:
/oraagent> du -sh agent12c
631M    agent12c
/oraagent> ls agent12c/core
12.1.0.2.0
/oraagent> du -sh agent12c/core/*
534M    agent12c/core/12.1.0.2.0
/oraagent> emctl status agent
Oracle Enterprise Manager Cloud Control 12c Release 2
Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved.
Agent Version     : 12.1.0.2.0
OMS Version       : 12.1.0.2.0
Protocol Version : 12.1.0.1.0
Agent Home        : /oraagent/agent12c/agent_inst
Agent Binaries    : /oraagent/agent12c/core/12.1.0.2.0Interestingly the inventory.xml in the oraInventory on the upgraded server still contains references to the 12.1.0.1.0 directory that seem useless:
<HOME NAME="agent12c2" LOC="/oraagent/agent12c/core/12.1.0.2.0" TYPE="O" IDX="1">
   <REFHOMELIST>
      <REFHOME LOC="/oraagent/agent12c/sbin"/>
      <REFHOME LOC="/oraagent/agent12c/plugins/oracle.sysman.db.discovery.plugin_12.1.0.2.0"/>
      <REFHOME LOC="/oraagent/agent12c/core/12.1.0.1.0/../../plugins/oracle.sysman.db.agent.plugin_12.1.0.2.0"/>
      <REFHOME LOC="/oraagent/agent12c/plugins/oracle.sysman.oh.discovery.plugin_12.1.0.2.0"/>
      <REFHOME LOC="/oraagent/agent12c/plugins/oracle.sysman.oh.agent.plugin_12.1.0.2.0"/>
      <REFHOME LOC="/oraagent/agent12c/plugins/oracle.sysman.emas.discovery.plugin_12.1.0.3.0"/>
      <REFHOME LOC="/oraagent/agent12c/plugins/oracle.sysman.xa.discovery.plugin_12.1.0.3.0"/>
   </REFHOMELIST>
</HOME>
<HOME NAME="OraHome6" LOC="/oraagent/agent12c/core/12.1.0.1.0/../../plugins/oracle.sysman.db.agent.plugin_12.1.0.2.0" TYPE="O" IDX="8">
   <DEPHOMELIST>
      <DEPHOME LOC="/oraagent/agent12c/core/12.1.0.2.0"/>
   </DEPHOMELIST>
</HOME>The agent upgrades were all performed through the agent upgrade console without incident. The OMS server itself also contains both 12.1.0.1.0 and 12.1.0.2.0 in the agent base core directory. The fact that the agent on the server that never had 12.1.0.1.0 installed is working fine would seem to indicate that the 12.1.0.1.0 binaries aren't required for proper functionality, but I'm just not clear on how to remove them. I would like to avoid losing the targets monitored by these agents and having to recreate them and their jobs and so on.
Any thoughts? Has anybody else had the same issue occur in their environment?

If you are talking about the target agent upgrade to 12.1.0.2 and there is core dir left behind then you can delete only the contents of the $AGENT_BASE_DIR/core/12.1.0.1.0 directory and make sure that
the directory $AGENT_BASE_DIR/core/12.1.0.1.0 exists
Just FYI: for next EM release, we have a proper feature: sign off process where all dangling old oracle homes, their disk foot pints plus oms side artifacts, for upgraded agents can be removed.
The Upgrade guide is also getting updated with same information, should be live in next 2-3 days. We have told the same to come of our customer like AT&T, Fedility ..etc
I would also like to share information on the thread:
Re: How to delete 12.1.0.1 OMS Home when it contains the 12.1.0.2 agent s/w?
The script/steps to move the agent home from old middleware home to new one while doing the Oms upgrade from 12.1.0.1 to 12.1.0.2 is also ready. We also provided this script to one of our customer and they verified this script ( works for them :) )
How to Migrate the AGENT BASE DIRECTORY under Middleware Home to another location outside the Middleware Home? (Doc ID 1520010.1)
Again upgrade guide is getting updated with this note number

12.1.0.3 Agent Upgrade shows agent Not Upgradable with Oracle Home Property Missing

I have completed upgrading my Enterprise Manager OMS from 12.1.0.1 to 12.1.0.3 and am not in the process of upgrading the agents. Several agents show agent as not upgradable with error Oracle Home Property Missing and I am having problems trying to resolve that. In addition to the information in Chapter 5 of the upgrade guide I have found Metalink notes 1564380.1 & 1576084.1 and am trying to follow them.
Looking at the targets.xml on one machine I find -
<Target TYPE="oracle_home" NAME="cannon-columbo_cluster_home" IDENTIFIER="TARGET_GUID=615AE33355A4D531DBFC35831C2A2952">
<Target TYPE="oracle_home" NAME="mothpa.ucdavis.edu_mothpa1_oracle_database_home" IDENTIFIER="TARGET_GUID=DFE64CFD805C3C3F88E20EE0E74E556F">
<Target TYPE="oracle_home" NAME="LISTENER_SCAN1_cannon-columbo_oracle_listener_home" IDENTIFIER="TARGET_GUID=964A37630D9E7E321E0EA845B79F5CD7">
and following the notes I use emctl and run runCollection -
./emctl control agent runCollection mothpa.ucdavis.edu_mothpa1_oracle_database_home:oracle_home oracle_home_config
But the console still shows Oracle Home Property Missing. emctl listtargets shows -
mothpa1:product/agent12g/agent_inst/bin->./emctl config agent listtargets
Oracle Enterprise Manager 12c Cloud Control 12.1.0.1.0
Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved.
[cannon.ucdavis.edu:3872, oracle_emd]
[LISTENER_cannon.ucdavis.edu, oracle_listener]
[cannon-columbo_cluster_home, oracle_home]
[mothpa.ucdavis.edu_mothpa1_oracle_database_home, oracle_home]
[LISTENER_SCAN1_cannon-columbo_oracle_listener_home, oracle_home]
[cannon.ucdavis.edu, host]
[mothpa.ucdavis.edu, rac_database]
[cannon-columbo, cluster]
[has_cannon.ucdavis.edu, has]
[ricep1_ricep11, oracle_database]
[mothpa_mothpa1, oracle_database]
[mothpa, rac_database]
[ricep1, rac_database]
[+ASM1_cannon.ucdavis.edu, osm_instance]
[+ASM_cannon-columbo, osm_cluster]
[LISTENER_SCAN1_cannon-columbo, oracle_listener]
I have found some information pertaining to promoting targets but I don't understand that very well, essentially how to know if a target needs to be promoted. One note suggested running repvfy which I need to do. I will download it and run it to see if that helps but at the moment I am puzzled and seeking assistance. Any suggestions gratefully appreciated.
Thank you.
Bill Wagman

I will do so, thank you.
Bill Wagman

Upgrade Agent to 11g to run on 10.2.05 repository

Hello.
I want to upgrade our 10.2.0.5 agent to 11.1.0.1.0 and have confirmed that this is supported via Certifications on Metalink.
Does anyone have experience of this procedure?
Regards,
DA.

Steps for the upgrade are thus:
Upgrade Procedure, as per Upgrading Oracle Management Agent Using a Response File from Oracle® Enterprise Manager Grid Control Advanced Installation and
Configuration Guide
11g Release 1 (11.1.0.1.0)
Part Number E16847-10
http://download.oracle.com/docs/cd/E11857_01/install.111/e16847/upgrade_agent_usng_rsp.htm#CEGIDJFC
To upgrade an existing Management Agent using a response file, follow these steps:
1.
Backup Agent Home and set Registration Password.
Backup the exisiting Agent Home
cp -R /oraoem/agent10g /oraoem/pre_upgrade_agent10g
set a Registration Password in Grid Control
In oraoem’s bash shell, set an environment variable for $AGENT_INSTALL_PASSWORD
2.
Prepare Response File.
Navigate to and edit the response file upgrade_agent.rsp as described here:
edit rsp file, as per Oracle doc, and set 2 values:
OLD_BASE_DIR
If you have the default name for the Oracle home of your existing Management Agent, that is, agent10g, then specify the path to the old installation base
directory where the Management Agent to be upgraded is residing.
For example, if the Management Agent is residing in /john/OracleHomes/10.2/agent10g, then specify only /john/OracleHomes/10.2/
ORACLE_AGENT_HOME_LOCATION
Specify the location where the Oracle home of the Management Agent (agent11g) can be created.
Therefore:
The old installation base directory where the Management Agent to be upgraded is residing =
OLD_BASE_DIR = /oraoem
ORACLE_AGENT_HOME_LOCATION = /oraoem/agent10g
3.
Stop the Agent and Invoke installation.
Stop the Management Agent you want to upgrade.
as oraoem emctl stop agent
Invoke the installer:
If you have the default name for the Oracle home of your existing Management Agent, that is, agent10g, then: run the following command:
./runInstaller -silent -responseFile /<path to upgrade_agent.rsp>
4.
Post upgrade tasks.
After you upgrade verify the installation:
emctl status agent
Run the following command to see a message that confirms that EMD upload completed successfully:
$<ORACLE_HOME>/bin/emctl upload
manually run the root.sh script as a root user from the Oracle home of the Management Agent:
as oraoem stop the agent
emctl stop agent
as root run the root.sh
<Oracle_Home>/root.sh
start agent
emctl start agent
DA

Upgrade OMServer.msi returned error 1603

Hi All,
I'm was updating a SCOM 2012SP1 to 2012R2 environment for a customer, but when upgrading the first Management server the following error occures;
------OpsMgrSetupWizard.txt-------
Error: :LaunchMSI: MSI E:\Setup\AMD64\Server\OMServer.msi returned error 1603
------OMServer.txt----------------
Product: System Center Operations Manager 2012 Server -- The Operations Manager management server cannot
be installed on a computer on which the Operations Manager agent, Operations Manager gateway, System Center Essentials,
or System Center Service Manager is already installed. These must be uninstalled to proceed.
Non of these applications were present on the Management Server, So, After returning serveral times to the snapshot;
I was monitoring the registy, the following entry was made during installation;
HKEY_CLASSES_ROOT\Installer\UpgradeCodes\C96403E8AD6025B4F9E1FE9C574E34AE
This entry didn't exists before the upgrade!! as seen in this tread [http://social.technet.microsoft.com/Forums/en-US/07675a55-d3e1-4b30-a25c-e85a846b9d00/omservermsi-returns-error-1603-when-trying-to-upgrade-first-management-server-from-operations?forum=operationsmanagerdeployment ]
Also within "Add or Remove Programs" the "Operations Manager Agent" was present.
After manual removing the "Operations Manager Agent" during the upgrade, the installation of OMServer.msi succesfully was continued and the upgrade could continue.
My question is; What the deuce happend here?
Kind Regards,
Maurice Kok

Verify that you install server prerequisites Both .NET Framework 3.5 Service Pack 1 (SP1) and .NET Framework 4 are required.
Also you can refer below link
http://scug.be/christopher/2013/01/24/scom-2012-sp1-omserver-msi-returned-error-1603/
Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question, please click "Mark As Answer"

10.2.0.4 Agent Pull Technique Upgrade

Similar Messages

Maybe you are looking for