Anyone upgraded to OME 1.3 yet?

Hi Dan and thanks for the post.

I wouldn't be too concerned with the large readme.  I think if you look, a lot of those are corner case issues that many folks won't see.  We've even gotten feedback on some of them that they are pretty obscure and we shouldn't bother to clutter the readme with them...anyway.

A couple of things...

There does seem to be one issue that is tripping up some folks who are upgrading from a previous version of OME.  If the have duplicate discovery ranges in the database, the upgrade might run into trouble.  This might happen if they've used the import discovery wizard feature or perhaps gotten some duplicates in the database some other way.  We are looking at that.

Always best to back up your SQL database regularly in any event, and especially when doing an upgrade or update to your system.

But a great way to do it is to just throw 1.3 on a new VM, discover a few devices and take a look at some of the new features.

Thanks again,

Rob

Made my day :)

Thanks Jiff.  Keep us posted on your progress.

Best regards,

Rob

Upgraded this AM and no issues for me either.

Wow! Feels great to hear to such nice news on forum :)

As I can see many success and now issues. I’m preparing to upgrade form 1.2 (not 1.2.1), but environment is quite big (current in inventory <400 server). Jiff, TRScott form with version did you upgraded?

... and my upgrade from 1.2 failed :( . This was FULL fail database, IIS configuration gone... Only restore from backup was possible. In installation log I can see:

Undefined exception occurred:
System.Data.SqlClient.SqlException (0x80131904): The ALTER TABLE statement conflicted with the FOREIGN KEY constraint "FK_Agent_DiscoveryConfiguration". The conflict occurred in database "OMEssentials", table "dbo.DiscoveryConfiguration", column 'Id'.
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async, Int32 timeout)
   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, String methodName, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite)
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
   at InstallUtil.Installers.Database.Database.RunScriptFile(SqlConnection sqlConnection, String filePath, String databaseName, String dataFilePath, String logFilePath)
   at InstallUtil.Installers.Database.Database.Install(DatabaseOptions databaseOptions)
   at InstallUtil.Program.RunInstall(CommandLineArgumentsDictionary arguments)
   at InstallUtil.Program.Main(String[] args)
ClientConnectionId:8985be4c-8c1a-4463-8e00-549d7b18c46e

I will open support call to DELL.

For now I'm running again with 1.2 (restored form backup )

Hm... I have few Discovery Group Ranges (with different credentials for inventory ) but with the same subnet IP as Discovery ranges. That mean one server can be discover by many Discovery Range but Inventory will success be one only.

Is that a problem ?

Borek.

Thanks for the post Borek,

Yeah, please proceed with the support call.  There seem to be some folks that have duplicate discovery ranges in their database and we're looking to see why that might be.

Did you, by chance, use the discovery range import button that imports a list of ranges into the wizard?

We're trying to pin it down.

In any event, we are in the process of re-posting the installer code/wrapper around 1.3 that will whack any errant duplicates that might exist in the database.  Until it is posted, the support guys can give it to you.

Thx much,

Rob

I am a first time user of OME, and am using 1.3. I am monitoring a group of 5 Linux servers (1 PowerEdge 320, and 4 PowerEdge 620). The servers are running a CentOS 6.4 -based OS. Each server is equipped with an iDRAC 7. After discovery and inventory, on the the 320 the operating system name is correctly displayed as CentOS; however, on the other servers the OS name is N/A. The problem is that for these servers firmware updates are assumed to be for windows. Not sure what I am missing.

All servers have a /etc/redhat_release file that starts "CentOS 6.4"

Any help would be much appreciated.

Thanks. Peter

Hi Peter, thanks for the note.

Can you let me know what version of OMSA you have installed on the servers?

You can also run the SNMP test from the OME Troubleshooting tool and see if it can make a connection.  To be successful, it needs to show the version of Server Administrator in the result set.

Thanks,

Rob

Rob,

  thanks for the quick response. I dont think that OMSA has been installed on the servers (I did not do it). I installed OME, and followed the instructions to configure ws-man to inventory via the iDRACs. Maybe OMSA should be installed?

Peter

Hi Peter,

OMSA is not a requirement when you are performing discovery and inventory through iDRAC-WSMAN.

• Can you please confirm, if the devices are discovered and inventoried properly and classified under RAC in the device tree?
• when you say Firmwares are assumed to be that for windows, can you please confirm where are you seeing this? A screenshot would help, you can clean up the parts which you dont want to show in the screenshot
• Is there a difference in the iDRAC firmware between your R320 and R620s? The firmware version would help us figure out more. 

I found my issue. This is duplicated record in DiscoveryConfiguration

select Address, count(*) as dup_sub_cnt from DiscoveryConfiguration

group by Address having count(*) > 1

One server is listed twice.

BTW: this is documented on: http://en.community.dell.com/techcenter/systems-management/f/4494/p/19565839/20579892.aspx

@Peter: what is the best way to correct this issue. Can I just remove this record form DiscoveryConfiguration table or we have some "hidden relation "

Borek.