12 Posts

April 12th, 2012 13:00

Sure, the current catalog shows as DellOnline, 'P3WXG', 3/6/2012, no newer version available.

Jason

Community Manager

 • 

711 Posts

April 12th, 2012 13:00

Hi,

Thanks for your post. Can you let us know if OME is showing the latest FTP catalog as the source. The Catalog information can be found under Manage->System Update and then clicking "View Active Catalog" link on the left hand side.

Regards

Abhijit

Community Manager

 • 

711 Posts

April 12th, 2012 14:00

Thanks for the update Jason.

The catalog is surely the latest. I can also see the package listed on the ftp.dell.com at the location mentioned in the error message you posted above.

Is it possible for you to try any other update. That will tell us if the error is shown for this specific package or is it a generic issue.

12 Posts

April 12th, 2012 15:00

Hi Abhijit,

You nailed it.  It appears that it was just the one package.  I have been able to push two BIOS updates with no issue.  Thanks for the help here.

Now on to the OMSA updates:

I'm trying to push the OMSA 7.0 package.  It seems to install but doesn't.  I specified my path locally to the .MSI package (SysMgmt_7_0_0.msi) which I extracted from the OMSA 7.0 download (OM-SrvAdmin-Dell-Web-WIN-7.0.0-4741_A00.exe)  On this server I'm attempting to go from OMSA 5.5

The installer seems to run, as I mentioned.  My results:

PackageStatus:   The Update Package was applied successfully.

PackageFileName:   C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\s6h4\SysMgmt.msi

PackageReleaseId:   Not Available

PackageState:   complete

TotalStatusMessage:   Software update complete.

And on the Event Viewer for the target server I even see:

Product: Dell OpenManage Server Administrator -- Installation operation completed successfully.

For more information, see Help and Support Center at go.microsoft.com/.../events.asp.

Data:

0000: 7b 44 44 41 30 34 41 43   {DDA04AC

0008: 33 2d 46 36 36 42 2d 34   3-F66B-4

0010: 37 45 30 2d 42 31 38 39   7E0-B189

0018: 2d 36 30 30 38 45 42 31   -6008EB1

0020: 44 38 30 41 32 7d         D80A2}  

But OMSA 5.5 is still installed on the target.  I even restarted my OMSA services.

Any ideas?  

Community Manager

 • 

711 Posts

April 12th, 2012 15:00

Thanks for the updates Jason. I'm glad that the other updates are working for you.

OMSA update takes certain Install Arguments. There white paper below will have more details.

en.community.dell.com/.../20069180.aspx

Easier way would be to clone the Sample - OMSA Upgrade Windows Task by right clicking and selecting clone. Then provide a name for the new task. Select the new task and click edit and provide the OMSA Package along with target and schedule. You are using the correct package. Let us know if this works.

12 Posts

April 12th, 2012 16:00

Abhijit,

I did use a clone for the task every time.  I'm not changing the parameters - only using a MSI as mentioned above.  I was able to install the MSI package manually.

I looked at the PDF and it seems to mirror the steps I'm taking with the clone.

Did you have any other common suggestions I may be missing?

Jason

Community Manager

 • 

711 Posts

April 13th, 2012 08:00

Thanks for the updates Jason. I think you are doing everything correct in that case. Cloning the right task, selecting the right package and I don't see any credential related errors.

Only other thing to try would be clearing the temp folder on the target. The OMSA package gets copied to C:Windows\Temp folder. It is possible that it may have older package there and OMSA services have cached it. Try clearing the temp folder, restart OMSA service and try the deployment again.

Regards

Abhijit  

12 Posts

April 16th, 2012 15:00

Abhijit,

I come armed with screenshots today!

I tried the steps you suggested and did a reexecute.  In this instance I get one line:

Package uploaded E:\Program Files\Dell\SysMgt\Essentials\SystemUpdate\Packages\SysMgmt_7_0_0.msi

For a second run - a different server - I renamed the package to 'sysmgmt.msi'

This one simply shows uploaded as complete but no further status.

In both cases I started the packages Friday afternoon (EST).  They're stuck at 0% since.  That's quite a lengthy install!

Let me know what else I can try.

Jason

12 Posts

April 16th, 2012 15:00

Abhijit,

A thought occurred to me when you asked about run now and mentioned the task manager.  Does the execution of the OMSA update rely on Scheduled Tasks?  On most servers in our environment we prohibit the use of Scheduled Tasks (it's a legacy setting due to a virus outbreak years ago)

Jason

Community Manager

 • 

711 Posts

April 16th, 2012 15:00

Thanks for the updates Jason.

OME does rely on Task Manager to execute multiple operations like discovery, inventory, getting health status, sending updates to the servers and deploying OMSA. All these operations are different tasks run by the task manager. You can either run those immidiately or schedule those to run in future. OME does not use windows task scheduler so if you have disabled scheduled tasks in Windows it should not impact OME tasks. For executing updates and OMSA deploy, OME uses an executable OMRemote.exe, you want to make sure that it is not blocked by Firewall.

Also let us know if Task Manager service picks up the task after restarting.

Regards

Abhijit

Community Manager

 • 

711 Posts

April 16th, 2012 15:00

Thanks Jason.

The update task shouldn't take this long. It usually takes few minutes due to file size but definitely not days. I believe you had selected run now as an option and not scheduled it for future time right?

I would check if the "DSM Esstentials Task Manager" service is running and try to restart it. Also can you check on the target server if OMSA is updated? Sometimes even after the task has finished the execution, the status is not updated on the OME server.

Regards

Abhijit

12 Posts

April 16th, 2012 18:00

Abhijit,

I did restart the OME Task Manager service.

I cleaned out C:\windows\temp and restarted the job for the target.

It seems in C:\windows\temp a package 'WindowsPreInstallPackage' appears after the job starts.  I believe it's extracted itself to C:\windows\temp\WindowsPreInstallPackage

I see a temp file also in C:\windows\temp

OMC2DEA.tmp;  it never goes past 0 bytes

Not sure what all else happens but things seem to stall out from here...

Hope this helps.

Jason

Community Manager

 • 

711 Posts

April 17th, 2012 08:00

Thanks for the updates Jason.

Is it possible that the account you are using for updates does not have administrative permissions on the target node? I'm talking about the windows account credentials you specify while creating the deployment task. Another thing to check would be any antivirus software running on the target which may block the execution.

Regards

Abhijit

12 Posts

April 30th, 2012 15:00

I worked with Dell support today and we used these switches for a successful update of OMSA 6.1 to OMSA 6.5:

REINSTALL=ALL REINSTALLMODE=VAMUS /qn

I hope this helps others.

Jason

No Events found!

Top