Recently, I’ve been engaged in a conversation on the OTN community pages about upgrading Oracle GoldenGate 12c from 126.96.36.199.0 to the 188.8.131.52.0. During the discussion I mentioned that you can upgrade using the Oracle Universal Installer (OUI) that is now available with Oracle GoldenGate 12c. The upgrade process I’m going to show you here is an in-place upgrade of Oracle GoldenGate 12c for Oracle Database 12c.
Note: Before doing any upgrades of Oracle GoldenGate, make sure to stop all processes and backup your existing binaries and associated files needed for your environment.
The first thing that needs to be done is to download the 184.108.40.206.0 binaries from either edelivery.oracle.com or My Oracle Support (Image 1).
After downloading the new binaries to a location where they can be extracted; they need to be unzipped.
$ unzip ./OracleGoldenGate12121.zip -d ./ggate12121
Once the binaries are unzipped, lets go into the ./ggate12121 directory to find the runInstaller. On my system the runInstaller is found at this location.
Before running the runInstaller, I need to make sure that all my Oracle GoldenGate processes are down. Since this is on my target (test) system, that means the manager, all replicats and collector processes should be stopped. A simple “ps -ef” command can help identify what is running.
$ ps -ef | grep dirpm oracle 2401 1 0 22:47 ? 00:00:00 ./mgr PARAMFILE /opt/app/oracle/product/12.1.2/oggcore_1/dirprm/MGR.prm REPORTFILE /opt/app/oracle/product/12.1.2/oggcore_1/dirrpt/MGR.rpt PROCESSID MGR USESUBDIRS oracle 2407 2401 1 22:47 ? 00:00:02 /opt/app/oracle/product/12.1.2/oggcore_1/replicat PARAMFILE /opt/app/oracle/product/12.1.2/oggcore_1/dirprm/REP.prm REPORTFILE /opt/app/oracle/product/12.1.2/oggcore_1/dirrpt/REP.rpt PROCESSID REP USESUBDIRS $ ps -ef | grep server oracle 2486 1848 0 22:51 pts/0 00:00:00 grep server
After identifying the processes, they need to be stopped from within GGSCI.
Oracle GoldenGate Command Interpreter for Oracle Version 220.127.116.11.0 17185003 OGGCORE_18.104.22.168.0_PLATFORMS_130924.1316_FBO Linux, x64, 64bit (optimized), Oracle 12c on Sep 25 2013 02:33:54 Operating system character set identified as UTF-8. Copyright (C) 1995, 2013, Oracle and/or its affiliates. All rights reserved. GGSCI (ggtest2.acme.com) 1> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING <br />REPLICAT RUNNING REP 45:06:32 00:04:35 GGSCI (ggtest2.acme.com) 2> stop er * Sending STOP request to REPLICAT REP ... Request processed. GGSCI (ggtest2.acme.com) 3> stop mgr ! Sending STOP request to MANAGER ... Request processed.<br />Manager stopped. GGSCI (ggtest2.acme.com) 9> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER STOPPED <br />REPLICAT STOPPED REP 45:14:08 00:00:05
To verify that everything has been stopped, the “ps -ef” command can be ran to verify. After verifying that everything is stopped, the runInstaller can be used to start the OUI for the upgrade (Image 2).
Notice that there are 5 steps to the OUI. Also notice that there is not an “upgrade” option. Not to worry, we can still perform the upgrade. Since this is an upgrade of Oracle GoldenGate 12c for Oracle Database 12c, make sure to select the option for Oracle Database 12c (default), then click the next button.
On the Installation screen, the location of the existing binaries need to be selected from the drop down box for Software Location. In the example, the location is /opt/app/oracle/product/12.1.2/oggcore_1. Also notice in image 3, that I do not want the manager process to start. After making sure everything is correct and as expected, click Next.
Note: The information on this screen is read from the oraInventory files. Make sure you know where the oraInventory located and set as needed.
The wizard now moves to the Summary screen (Image 4). On this screen, the typical information is seen. Click Install when ready.
Image 5 shows the progress of the install/upgrade.
After the install/upgrade is done (Image 6), we get a nice message saying that it was successful.
Once the upgrade is complete, then the Oracle GoldenGate processes (manger, replicats) can be restarted. Notice that the version of Oracle GoldenGate 12c that is running now is 22.214.171.124.0
[oracle@ggtest2 Disk1]$ cd /opt/app/oracle/product/12.1.2/oggcore_1 [oracle@ggtest2 oggcore_1]$ pwd /opt/app/oracle/product/12.1.2/oggcore_1 [oracle@ggtest2 oggcore_1]$ . oraenv ORACLE_SID = [oracle] ? remote12c The Oracle base has been set to /opt/app/oracle [oracle@ggtest2 oggcore_1]$ ./ggsci Oracle GoldenGate Command Interpreter for Oracle Version 126.96.36.199.0 OGGCORE_188.8.131.52.0_PLATFORMS_140727.2135.1_FBO Linux, x64, 64bit (optimized), Oracle 12c on Aug 7 2014 10:21:34 Operating system character set identified as UTF-8. Copyright (C) 1995, 2014, Oracle and/or its affiliates. All rights reserved.</p> <p>GGSCI (ggtest2.acme.com) 1> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER STOPPED <br />REPLICAT STOPPED REP 45:14:08 00:24:08 GGSCI (ggtest2.acme.com) 2> start mgr Manager started. GGSCI (ggtest2.acme.com) 3> start replicat rep Sending START request to MANAGER ... REPLICAT REP starting GGSCI (ggtest2.acme.com) 4> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING REPLICAT RUNNING REP 45:39:08 00:00:01
As you can tell the upgrade from Oracle GoldenGate 12c (184.108.40.206.0) to Oracle GoldenGate 12c (220.127.116.11.0) can be completed using the Oracle Universal Installer that now comes with Oracle GoldenGate 12c. I wish Oracle would give an option for an upgrade in the OUI, it would cut down on some confusion when it comes to upgrades with Oracle GoldenGate using the OUI.
Filed under: Golden Gate
Working on Oracle GoldenGate can be an interesting adventure. In such a case, I have been doing some migration work for a client. Half way though the migration, the target system ran out of resources need to create the tablespaces and store files export and trail files (i.e. disk space and a story for another time). The impact to the migration was that everything had to stop until resources were allocated.
Part of the allocation of resources was to change the mount point name. If you know anything about Oracle GoldenGate Replicats, using a static mount point is not the best approach (slipped my mind at the time); however, I made this mistake. When the mount point name changed, all the replicats broke because they couldn’t locate the trail files where specified.
When I initially setup the replicat I used a static mount point. Let’s take a look at the create replicat statement I used initially:
--Add Replicat Process ADD REPLICAT REPM01, EXTTRAIL /orabackup/ggate/trail/ars/ra, DESC "Replicat process for a schema” START REPLICAT REPM01, ATCSN
As you can see the replicat is looking for the “ra” trail files on the “/orabackup” mount point.
During the allocation of space the mount point “/orabackup” was changed to “/orabkup”. How does this affect the replicat? Simple, the replicat will through an OGG-01091 error stating that it coudn’t find the trail file.
ERROR OGG-01091 Unable to open file “/orabackup/ggate/trail/ars/ra000000″ (error 2, No such file or directory).
The solution to fixing this problem is to capture the last CSN number from the Checkpoint table.
SQL> select group_name, rba, seqno, log_cmplt_csn from checkpoint where group_name = 'REPM01'; GROUP_NA RBA SEQNO LOG_CMPLT_CSN -------- ---------- ---------- ----------------------------------- REPM01 544013 1 11108080706671
Once the last completed CSN has been identified, then the replicat can be dropped, recreated with the new path to the trail file.
GGSCI> dblogin userid ggate password GGSCI> delete replicat REPM01 GGSCI> add replicat REPM01, EXTTRAIL /orabkup/ggate/trail/ars/ra, DESC "Replicat process for a schema” GGSCI> start replicat REPM01, atcsn 11108080706671 GGSCI> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING REPLICAT RUNNING REPM01 00:00:00 00:00:06
When setting up locations for your trail files make sure they are not static locations. Realitve locations should be used. In most Oracle GoldenGate architectures the “dirdat” directory under $OGG_HOME is used for trails files; however, if you need more space for trail files the “dirdat” directory can be linked to a directory on a larger mount point. This will keep the replicat consistant for trail file purposes and make it easier to manage the names of the mount point if the static name changes.
Filed under: Golden Gate
Last week I attended the East Coast Oracle User Group conference, also known as ECO, in Raleigh, NC. This being my first time at ECO, it was a good event for being a two day conference. The low-key environment provided a nice, comfortable environment for interaction between the speakers and those in attendance. If you ever have the chance to catch this conference, it would be a good one to attend.
What you can expect from ECO, is to see great speakers, both local to Raleigh and from around the country. There seems to be opportunities to see also see speakers that we all hear about and would like to see at some point. As one of the speakers at this year’s conference, I have to say it was nice to have great attendance for my session on Oracle GoldenGate 12c Conflict Detection and Resolution. My session was scheduled for 45 minutes; due to discussions throughout the session it lasted about 65 minutes. Although the session ran over, it was exciting to see so many people wantiong to know more about Oracle GoldenGate and what benefits it provides to an organization.
If you would like to see the slides from my ECO session, they can be found here.
Lastly, I would like to say that ECO is one of the smaller user group conferences which seem to draw some great speakers. Check it out next year!
Filed under: General
Recently, Enkitec received an Oracle Big Data Appliance (BDA) for our server farm in Dallas (Thanks Accenture!). With this new addition to the server farm, I’m excited to see what the BDA can do and how to use it. Since I use Oracle SQL Developer for a lot of things, I figure I better see if I can connect to it…. wait I don’t have access yet, darn! Simple solution, I’ll just use the Oracle Virtual Box VM (Big Data Lite) to make sure my that my SQL Developer can connect when I eventually get access.
The first thing I needed is download the Big Data Lite VM. It can be downloaded from the Oracle Technology Network (here). The second thing I needed to do was download the connectors for HIVE from Cloudera, use the version for the platform you need (here).
After downloading the Cloudera connectors for HIVE, these needed to be unzipped in a location that can be accessed by SQL Developer. Since I’m on a MacBook Pro, I unzipped them in this location:
$ cd ~/Downloads $ unzip ./Cloudera_HiveJDBC_18.104.22.1686.zip -d /Users/Bobby/Oracle/connectors $ cd /Users/Bobby/Oracle/connectors $ ls -ltr total 21176 -rw-r--r--@ 1 Bobby staff 5521341 Sep 10 15:16 Cloudera_HiveJDBC4_22.214.171.1246.zip -rw-r--r--@ 1 Bobby staff 5317239 Sep 10 15:16 Cloudera_HiveJDBC3_126.96.36.1996.zip $ unzip ./Cloudera_HiveJDBC4_188.8.131.526.zip -d ./Hive $ cd ./Hive $ ls -ltr -r--r--r--@ 1 Bobby staff 1083758 Sep 8 17:28 Cloudera - Simba JDBC Driver for Hive Install Guide.pdf -rw-r--r--@ 1 Bobby staff 9679 Sep 8 23:28 slf4j-log4j12-1.5.8.jar -rw-r--r--@ 1 Bobby staff 23445 Sep 8 23:28 slf4j-api-1.5.8.jar -rw-r--r--@ 1 Bobby staff 367444 Sep 8 23:28 log4j-1.2.14.jar -rw-r--r--@ 1 Bobby staff 347531 Sep 8 23:28 libthrift-0.9.0.jar -rw-r--r--@ 1 Bobby staff 275186 Sep 8 23:28 libfb303-0.9.0.jar -rw-r--r--@ 1 Bobby staff 294796 Sep 8 23:28 ql.jar -rw-r--r--@ 1 Bobby staff 596600 Sep 8 23:28 hive_service.jar -rw-r--r--@ 1 Bobby staff 7670596 Sep 8 23:28 hive_metastore.jar -rw-r--r--@ 1 Bobby staff 2972229 Sep 8 23:28 TCLIServiceClient.jar -rw-r--r--@ 1 Bobby staff 1656683 Sep 8 23:29 HiveJDBC4.jar
Once the connectors are extracted, SQL Developer needs to know which HIVE connector to use. In this case the JDBC4 connector is required. Unzipped the JDBC4 set of files into a directory, in my case I’m using a directory called Hive.
In order to tell SQL Developer which connector to use, it needs to be specified in the interface by doing the following:
- Start SQL Developer
- Oracle SQL Developer -> Preferences
- Database -> Third Party JDBC -> Add Entry
- Restart SQL Developer
After restarting SQL Developer, we now see an option on the connection screen for Hive.
Now SQL Developer is ready to connect to a Big Data Appliance, oh I mean to my VM for Big Data Lite :), lets setup a connection and see if we can connect. Since I’m connecting to a Virtual Box VM, I need to setup some ports to be used between my MacBook and the VM. In this case, I have setup a SQL port on 15211 which maps to the standard database port of 1521. For the Hive connection I’ve setup 10001 which maps to port 10000.
With the ports put in place, now I can setup SQL Developer to connect to the Hive on the Big Data Lite VM. You will notice that on the username, password, server name and port is needed. The database parameter is optional when connecting to a Bid Data Hive.
Once the connection is configured, I can login to the Hive and review what tables are listed in the Big Data Lite VM.
The end result is that now I can visualize the data that is in a Big Data Appliance/Lite VM and begin to interact with objects defined within.
Filed under: BigData
Security is always a big deal. In setting up Oracle GoldenGate the capture (extract) and apply (replicat) parameter files need to be configured to log in to the database which they will perform operations. In order to do this the Oracle GoldenGate User name and password need to be provided in the parameter files. Example 1 shows how the database login is traditionally done in a extract or replicat parameter file.
--Oracle Login USERID ggate, PASSWORD ggate
To make this process login information more secure, we can create a userid alias that the extract or replicat process can use to log into the database. In order to create a login alias, a credential store needs to be create. Below are the steps to create the credential store and associated aliases.
After logging into the GoldenGate Service Command Interface (GGSCI), a credential store needs to be created. By default the credential store will be kept in the “dircrd” directory undert the $OGG_HOME.
Create the credential store:
GGSCI (db12cgg.acme.com) 1> add credentialstore Credential store created in ./dircrd/.
With the credential store created, now an alias can be created for the gguser.
GGSCI (db12cgg.acme.com) 2> alter credentialstore add user ggate, password ggate alias aggate Credential store in ./dircrd/ altered.
The extract or replicat parameter files need to be updated to use the new alias. Once the update is done the associated process needs to be restarted.
--Oracle Login USERIDALIAS aggate
After restarting the process, the Oracle GoldenGate login is secure.
Note: If the password for the Oracle GoldenGate User changes, the alias in the credential store will need to be updated.
Filed under: Golden Gate
Every once in awhile I do something in my test environments to test something else, then I go back to test core functions of the product; in this case I was testing a feature of Oracle GoldenGate 12c. Earlier in the day, I had set the $ORACLE_HOME enviornment variable to reference the Oracle GoldenGate home. Instead of closing my session and restarting, I just started GGSCI and the associated manager. To my surprise, the extracts that I had configured wouldn’t start. GGSCI was issuing an OGG-01742 error about the “child process is no longer alive” (Image 1).
As I was trying to figure out what was going on, I checked the ususal files (ggserr.log and report files) for any associated errors. I didn’t find anything that was out of place or lead me to believe there was a problem with Oracle GoldenGate. The next thing I needed to identify was if the environment was configured correctly. In doing this, I first checked the session environment variables (Image 2) related to the Oracle database.
As you can see, I had set the ORACLE_HOME equal to my OGG_HOME. After seeing this, I remembered that I had set it this way for a specific test. Since the ORACLE_HOME was set to OGG_HOME, the Oracle GoldenGate Extract (capture) process didn’t know where to get the needed libraries for the database.
To fix this issue, I just needed to reset my environment to reference the ORACLE_HOME and ORACLE_SID correctly. In Linux enviornment, I like to use “. oraenv” to do this (Image 3).
Now that I have reset my Oracle environment to point to the database, I should be able to start my extracts and not get any error messages related to OGG-01742 (Image 4).
Note: It appears that if the manager process has AUTOSTART and/or AUTORESTART set, the manager process needs to be restarted before the OGG-01742 message will go away.
With my extracts started now, I’ve got all my Oracle GoldenGate processes back up and running (Image 5).
In a nutshell, if you get OGG-01742 error while trying to start or restart an extract (capture) process; just reset your Oracle environment parameters!
Filed under: Golden Gate
Recently on I was strolling the OTN message boards and came across a question about identifying the version of Oracle GoldenGate using OPatch. This was the second time I came across this question; with that I decided to take a look and see if Oracle GoldenGate information could be retrieved using opatch.
Initially I thought that identifing the Oracle GoldenGate version could only be done by logging into GGSCI and reviewing the header information. To do this, just setup the Oracle environment using “. oraenv”.
Note: “. oraenv” will use the /etc/oratab file to set the ORACLE_HOME and ORACLE_SID parameters and ensure that Oracle GoldenGate has access to the library files needed.
Once the enviornment is set, the GGSCI can be used to start the interface.
[oracle@db12cgg ogg]$ . oraenv ORACLE_SID = [oragg] ? The Oracle base has been set to /u01/app/oracle [oracle@db12cgg ogg]$ ./ggsci Oracle GoldenGate Command Interpreter for Oracle Version 184.108.40.206.0 OGGCORE_220.127.116.11.0_PLATFORMS_140727.2135.1_FBO Linux, x64, 64bit (optimized), Oracle 12c on Aug 7 2014 10:21:34 Operating system character set identified as UTF-8. Copyright (C) 1995, 2014, Oracle and/or its affiliates. All rights reserved. GGSCI (db12cgg.acme.com) 1>
Notice in the code above, that the version of Oracle GoldenGate being ran is 18.104.22.168.0 for Linux x64.
How can this be done through OPatch? The same information can be gathered using the opatch utility. Ideally, you will want to use opatch from the $GG_HOME/OPatch directory.
Note: $ORACLE_HOME needs to be set to $OGG_HOME before correct opatch inventory will be listed. If $ORACLE_HOME is set for the database, the opatch will return information the database not Oracle GoldenGate.
After making sure that the $ORACLE_HOME directory is pointed to the correct $GG_HOME, the inventory for Oracle GoldenGate can be retrieved using “./opatch lsinventory”.
[oracle@db12cgg ogg]$ pwd /u01/app/oracle/product/12.1.2/ogg [oracle@db12cgg ogg]$cd OPatch [oracle@db12cgg OPatch]$./opatch lsinventory Invoking OPatch 22.214.171.124.7 Oracle Interim Patch Installer version 126.96.36.199.7 Copyright (c) 2011, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/12.1.2/ogg Central Inventory : /u01/app/oraInventory from : /etc/oraInst.loc OPatch version : 188.8.131.52.7 OUI version : 184.108.40.206.0 Log file location : /u01/app/oracle/product/12.1.2/ogg/cfgtoollogs/opatch/opatch2014-10-28_11-18-49AM.log Lsinventory Output file location : /u01/app/oracle/product/12.1.2/ogg/cfgtoollogs/opatch/lsinv/lsinventory2014-10-28_11-18-49AM.txt -------------------------------------------------------------------------------- Installed Top-level Products (1): Oracle GoldenGate Core 220.127.116.11.0 There are 1 products installed in this Oracle Home. There are no Interim patches installed in this Oracle Home. -------------------------------------------------------------------------------- OPatch succeeded.
As you can tell, I was able to find the same information using OPatch without having to go to the GGSCI utility.
Note: I have not had a chance to check this against Oracle GoldenGate 11g and earlier. This may be something specific to Oracle GoldenGate 12c. Will verify at a later time.
Filed under: Golden Gate
Ok Folks, I’ve been here are Oracle Open World for a few days now. In that time, I’ve had numerous conversations about running Oracle Enterprise Manager 12c on Oracle Database 12c. I will be honest and say that I’ve enjoyed these conversations; however, after about the fourth time I decided I need to write a quick post on the explanation discussed in these conversations.
Early this year (August) I wrote a post about the what came out of the OEM CAB in May 2014 and how to get OEM 12c to work on DB12c. The concept of running OEM 12c on DB12c, pluggable or not, have many people excited and looking forward to configuring OEM to do that very configuration. Heck, I’ve even installed it for a few customers in that configuration (non-PDB). So I’m a bit sad in having to say this: ORACLE DATABASE 12c SUPPORT FOR THE REPOSITORY DATABASE IS TEMPORARILY SUSPENDED! I say this due to the My Oracle Support (MOS) Note: 1920632.1.
Note 1920632.1 states the following:
Due to some recently discovered scenarios, we (Oracle) are temporarily suspending the certification of DB 18.104.22.168 and DB 22.214.171.124 as a Certified Repository version for EM 12c R4 until additional testing is complete.
Now what does this mean for those customers and clients that have already built their OEM 12c repository on DB 12c (126.96.36.199 or 188.8.131.52)? The MOS note outlines what to do in the action section of the note:
Until testing is complete on the 12c Database, Oracle recommends using DB 184.108.40.206 as the EM 12c R4 Repository.
If you are currently running a 12c DB repository, please be aware that additional testing is underway and there are currently no bugs or patches required; but if testing proves a patch is required, we will update this announcement. You do not need to deinstall EM 12c or move the repository to an 220.127.116.11 database.
Sure hope Oracle quickly finishes testing and can restore support for DB 12c as the OEM repository. In the meantime, everyone should know about this note number and be aware when making architecture changes related to their OEM 12c environment.
Filed under: OEM
This week I’ve been enjoying spending some time at Oracle Open World in San Francisco, CA. While here, I’ve been talking with everyone, friends old and new, and it came to my attention that it would be a good idea to have some useful templates for Oracle GoldenGate parameter files. With this in mind, I decided to create some generic templates with comments for Oracle GoldenGate processes. These templates can be found on my Scripts page under “Oracle GoldenGate Parameter Templates”. These files are in a small zip file that can be downloaded, unzipped and used in creating a basic uni-directional configuration.
By using these templates, you should be able to do:
- Review useful examples for each Oracle GoldenGate process (Manager, Extract, Pump, Replicat)
- With minor changes, quickly get uni-directional replication going
- Gain a base understanding of what how simple Oracle GoldenGate parameter files work
Filed under: Golden Gate
When I normally start work on a new EM 12c environment, I would request to have a userid created; however, I don’t have a userid in this environment and I need access EM 12c as SYSMAN. Without knowing the password for SYSMAN, how can I access the EM 12c interface? The short answer is that I can change the SYSMAN password from the OS where EM 12c is running.
Before changing the SYSMAN password for EM 12c, make sure to understand the following:
- SYSMAN is used by the OMS to login to the OMR to store and query all activity
- SYSMAN password has to be changed at both the OMS and OMR to EM 12c to work correctly
- Do not modify the SYSMAN or any other repository user at the OMR level (not recommended)
The steps to change an unknown SYSMAN password is as follows:
Tip: Make sure you know what the SYS password is for the OMR. It will be needed to reset SYSMAN.
1. Stop all OMS processes
cd <oms home>/bin
emctl stop oms
2. Change the SYSMAN password
cd <oms home>/bin
emctl config oms -change_repos_pwd -use_sys_pwd -sys_pwd <sys password> -new_pwd <new sysman password>
In Image 2, notice that I didn’t pass the password for SYS or SYSMAN on the command line. EMCTL will ask you to provide the password if you don’t put it on the command line.
3. Stop the Admin Server on the primary OMS and restart OMS
cd <oms home>/bin
emctl stop oms -all
emctl start oms
4. Verify that all of OMS is up and running
cd <oms home>/bin
emctl status oms -details
After verifying that the OMS is backup, I can now try to login to the OMS interface.
As we can see, I’m able to access OEM as SYSMAN now with the new SYSMAN password.
Filed under: OEM
One question I get asked a lot is “how can I add additional agent software to OEM 12c”? The answer is pretty easy; just download and apply to the software library. Now what does that mean? In this post, I’ll explain how to download additional agents for later deployments to other platforms.
After logging into OEM 12c, go to the Setup -> Extensibility -> Self Update (Image 1).
Once on the Self Update page (Image 2), there are a few things to notice. The first thing is that under Status, the Connection Mode is Online. This is an indicator that OEM has been configured and connected to My Oracle Support (MOS). Additional items under the Status area is when was the last refresh, last download time and the last download type. Right under the Status section there is a menu bar with actions that can be performed on this page. Clicking the Check Updates button will check for any new updates in all the Types listed. Since we want to focus on Agents, click on the folder for Agent Software.
After clicking on the Agent Software folder, it takes us to the Agent Software Updates page for Self Updates (Image 3). On this page, it can be seen clearly that there are a lot of agent software available. On this page, we can see the Past Activities where we can see what actions have been performed against a particular version of the agent.
On the menu bar (Image 4), we can search the agent software by either description or by example. These search options take text search terms. If we know there is a new release, it can be searched my simply entering text like ’18.104.22.168’.
As we can see in Image 5, searching for agents that are the version ’22.214.171.124’, we get a list of available agents with that version. Notice the Status column of the table. There are two types of status listed. These are two of the three statuses available. The third status is Downloading; which indicates that a new agent is downloading. The two status listed in Image 5 are: Applied and Available.
Let’s define the Agent Software Update Statuses a bit more. They are as follows:
- Available = This version of the agent is available for the OS Platform and can be downloaded
- Download in progress = This version of the agent is being downloaded to the OMS
- Downloaded = This version of the agent has been downloaded to the OMS
- Applied = This version of the agent has been applied to the Software Library and ready to use for agent deployments
Now that we know what the Status column means, how can an agent be downloaded?
While on the Agent Software Updates page, select and highlight an OS Platform that an agent is needed for. In this example, lets use “Microsoft Windows x64 (64-bit)” (Image 6). Notice the Status column and Past Activities section. This agent is available for download. Download the agent by clicking the download button in the menu bar.
After clicking the Download button, OEM will ask you when to run the job (Image 7). Normally running it immediately is fine.
Once the Status is set Downloaded, the agent software needs to be applied to the Software Library before it can be used (Image 8). Highlight the agent that was just downloaded and click the Apply button. This will apply the binaries to the software library. Also notice the Past Activities section; here we can clearly see what has been done with these agent binaries.
Once the Apply button has been clicked, OEM presents a message letting you know that the Apply operation will store the agent software in the software library (Image 9). Click OK when we are ready.
The agent software is finally applied to the Software Library and ready to use (Image 10).
With the agent now applied to the Software Library, it can be used to deploy out to, via push or pull, Microsoft Windows hosts.
Note: In my experience most deployments to Microsoft Windows host have to be done with there with Cygwin or Silent installed. If you would like more information on the silent install approach, I wrote a post on it here.
Filed under: OEM