Systems Management Forums

Issues with System Updates and Remote Tasks (OMSA)

Systems Management

Systems Management
Dell Systems Management Solutions: Dell OpenManage, iDRAC, Repository Manager, Microsoft SCCM, Chassis Managment Controller, and more

Issues with System Updates and Remote Tasks (OMSA)

  • I recently upgraded ITA to OME 1.0.1.1253.  Running on Windows 2008 32-bit with a local SQL install.

    I am not able to get System Updates or Remote Tasks (for OMSA upgrades) to work properly.

    First, System Updates.  I tried to deploy a hard drive update to a Windows 2003 x64 Standard Server running OMSA 7.0.  The task immediately shows success (100%) but it failed with the following error:

    Invalid package path FOLDER22225M/1/FRMW_WIN_R310809.EXE

    I find that the package path exists on the OME server.

    I tried using a local repository I created with Dell Repository Manager (Server) and I tried using the repository from ftp.dell.com  Both came back with the same result.

     

  • 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

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

    Jason

  • 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.

  • 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?  

  • 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.

  • 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

  • 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  

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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