Based on the information available, looks like after the update deployment is initiated OME is not able to connect to the target machine to get the software update status and the connection timed out after 30 minutes with multiple attempts.
1) What component update (Driver, BIOS, Firmware) user is trying to execute ?
2) Is the target machine getting restarted after the update ?
3) Is the OME machine and target machine in same domain or do they have domain trust established?
4) Is target machine changing IP address after it restarts from the update ?
You mentioned after running inventory the component shows compliant for a while and starts showing non-compliant again, is the updated component getting reflected in software inventory under Device details page (Manage -> Devices).
It may take some time for OMSA to pick up the updated inventory. Can you manual run inventory after 20 minutes and check if the same update components are showing as applicable in compliance report.
1) Normally, I try to update everything that OME is suggesting which includes drivers, BIOS, firmware, etc. Yesterday, I was installing just drivers which I've read somewhere that the server doesn't need to reboot after updating.
2) I have checked the box that says reboot if necessary (or something to that effect).
3) OME and the servers are in the same domain.
4) No, the servers all have a static IP address.
Yesterday's update installed, but I had no way to know if it was successful or not. After about an hour or so of pretty much constant Check Inventory updates, the server became compliant.
So whenever I execute a system update task, it's normal that the task always errors out? There has to be a way to make the system update task end successfully... And hopefully quickly...
Sorry as you are not getting prompt replies. Most of our folks are on leave due to Christmas and New Year's eve.
As you have mentioned, yesterday's update installed and but you have no way to check if it was successful or not but after consistent reinventory it felt under compliant systems. This means that the update was successful. After the update ran, OME was not able to connect to the device because of which you got fail system update message.
Can you verify during the system update task is running if you are able to connect to the target sever from OME machine? That might help us.
Yes, I was logged in to the server that was being updated and opened Task Manager to see if the system updates were being executed. It was and my assumption that the updates were completed successfully. What I don't understand is why OME is not able to connect to the server (and the system update task to state that it completed successfully) even though I am logged in to the server (to ensure that it was still up and running).
There were a few times in which I have executed system updates (which failed according to OME) (and which needed to reboot since there was a lot of updates taking place like BIOS, etc) and even though I ran and reran inventory updates numerous times, it looked as though it installed a few updates and I've had to create another system update task to finish the rest. Is that normal?
Being logged in to the server and able to connect from OME will be 2 different things. There are occasions when after system update, the system becomes unreachable from a remote location. OMe needs to connect to the target server using OMSA installed on the target server if you are doing a system update via OMSA method.
It is not normal for tasks to fail when they have already applied but can happen depending on various network features and which DUP you are trying to update. Now since you have mentioned you normally apply all packages it is possible that the targey system goes to unreachable mode for sometime. I would suggest you to try by applying one of the DUPs (packages) to target server and let us know if it still fails.
I apologize. I should've been more specific. When I mentioned that I was logged in, I meant to say that I was logged in remotely via Remote Desktop. Does that make a difference?
Could OMSA be unreachable? That could be the reason why I am still remotely logged in yet OME system update tasks fail.
Yes, it is possible that target server becomes unreachable via OME for some time after applying any system update. Some updates do make the system unstable for some time, in such cases OME will not be able to reach the system. That is why we have kept a time out of 30 minutes, so that if the server stays unreachable from OME for 30 minutes, then the task fails and completes instead of going on forever. If on doing a re inventory you are able to see that the update is applied, it means that the server was unreachable from OME
Can you please recommend what the best way in applying system updates then? Because of this issue, my maintenance window has to be increased... Is there a way to know which updates require a system reboot and which do not?
The above mentioned information should help. Let us know if it does. I will suggest you to use DUPs which require reboot separately in this case as your servers are becoming unreachable. OME is intelligent to take care of sequence in which the DUPs are applied and the DUPs which require ipdate are applied at last. But in a situation like this where the server is becoming unreachable on appyling an update, i will suggest you to apply updates which require reboot in a separate task and the ones which do not require reboot in a separate one.
DELL-Raj S
327 Posts
0
December 6th, 2012 11:00
Based on the information available, looks like after the update deployment is initiated OME is not able to connect to the target machine to get the software update status and the connection timed out after 30 minutes with multiple attempts.
1) What component update (Driver, BIOS, Firmware) user is trying to execute ?
2) Is the target machine getting restarted after the update ?
3) Is the OME machine and target machine in same domain or do they have domain trust established?
4) Is target machine changing IP address after it restarts from the update ?
You mentioned after running inventory the component shows compliant for a while and starts showing non-compliant again, is the updated component getting reflected in software inventory under Device details page (Manage -> Devices).
It may take some time for OMSA to pick up the updated inventory. Can you manual run inventory after 20 minutes and check if the same update components are showing as applicable in compliance report.
Thanks,
Raj Shresta
dajonx
2 Intern
•
294 Posts
0
December 6th, 2012 11:00
Thank you for your response, Raj.
1) Normally, I try to update everything that OME is suggesting which includes drivers, BIOS, firmware, etc. Yesterday, I was installing just drivers which I've read somewhere that the server doesn't need to reboot after updating.
2) I have checked the box that says reboot if necessary (or something to that effect).
3) OME and the servers are in the same domain.
4) No, the servers all have a static IP address.
Yesterday's update installed, but I had no way to know if it was successful or not. After about an hour or so of pretty much constant Check Inventory updates, the server became compliant.
So whenever I execute a system update task, it's normal that the task always errors out? There has to be a way to make the system update task end successfully... And hopefully quickly...
dajonx
2 Intern
•
294 Posts
0
December 7th, 2012 12:00
Can anyone help?
dajonx
2 Intern
•
294 Posts
0
December 18th, 2012 09:00
Any assistance?
dajonx
2 Intern
•
294 Posts
0
December 19th, 2012 10:00
Can someone please tell me how to create a case ticket so a Dell tech could look into this?
cameronredux
2 Intern
•
615 Posts
0
December 19th, 2012 10:00
support.us.dell.com/.../contact_technical_support
dajonx
2 Intern
•
294 Posts
0
December 19th, 2012 11:00
Thank you
DELL-Pupul M
2 Intern
•
1K Posts
0
December 20th, 2012 01:00
Hi,
Sorry as you are not getting prompt replies. Most of our folks are on leave due to Christmas and New Year's eve.
As you have mentioned, yesterday's update installed and but you have no way to check if it was successful or not but after consistent reinventory it felt under compliant systems. This means that the update was successful. After the update ran, OME was not able to connect to the device because of which you got fail system update message.
Can you verify during the system update task is running if you are able to connect to the target sever from OME machine? That might help us.
Thanks
Pupul
dajonx
2 Intern
•
294 Posts
0
December 20th, 2012 05:00
Thank you for your response, Pupul.
Yes, I was logged in to the server that was being updated and opened Task Manager to see if the system updates were being executed. It was and my assumption that the updates were completed successfully. What I don't understand is why OME is not able to connect to the server (and the system update task to state that it completed successfully) even though I am logged in to the server (to ensure that it was still up and running).
There were a few times in which I have executed system updates (which failed according to OME) (and which needed to reboot since there was a lot of updates taking place like BIOS, etc) and even though I ran and reran inventory updates numerous times, it looked as though it installed a few updates and I've had to create another system update task to finish the rest. Is that normal?
DELL-Pupul M
2 Intern
•
1K Posts
0
December 20th, 2012 06:00
Hi,
Being logged in to the server and able to connect from OME will be 2 different things. There are occasions when after system update, the system becomes unreachable from a remote location. OMe needs to connect to the target server using OMSA installed on the target server if you are doing a system update via OMSA method.
It is not normal for tasks to fail when they have already applied but can happen depending on various network features and which DUP you are trying to update. Now since you have mentioned you normally apply all packages it is possible that the targey system goes to unreachable mode for sometime. I would suggest you to try by applying one of the DUPs (packages) to target server and let us know if it still fails.
Thanks
Pupul
dajonx
2 Intern
•
294 Posts
0
December 21st, 2012 05:00
I apologize. I should've been more specific. When I mentioned that I was logged in, I meant to say that I was logged in remotely via Remote Desktop. Does that make a difference?
Could OMSA be unreachable? That could be the reason why I am still remotely logged in yet OME system update tasks fail.
DELL-Pupul M
2 Intern
•
1K Posts
0
December 23rd, 2012 23:00
Yes, it is possible that target server becomes unreachable via OME for some time after applying any system update. Some updates do make the system unstable for some time, in such cases OME will not be able to reach the system. That is why we have kept a time out of 30 minutes, so that if the server stays unreachable from OME for 30 minutes, then the task fails and completes instead of going on forever. If on doing a re inventory you are able to see that the update is applied, it means that the server was unreachable from OME
Thanks
Pupul
dajonx
2 Intern
•
294 Posts
0
December 26th, 2012 05:00
Thank you, Pupul.
Can you please recommend what the best way in applying system updates then? Because of this issue, my maintenance window has to be increased... Is there a way to know which updates require a system reboot and which do not?
DELL-Nitin Bh
43 Posts
0
December 26th, 2012 22:00
Hi,
Below information will help you to know the behavior of System Firmware and Device Firmware and its Behavior on update.
System Firmware:
BIOS Firmware :: Reboot required
ESM Firmware :: Reboot required
BMC Firmware :: Reboot not required.
Device Firmware:
PERC Firmware :: Reboot required
RAC Firmware :: Reboot not required
CERC Firmware :: Reboot required
SAS Firmware :: Reboot required
SCSI BP Firmware :: Reboot required
SAS BP Firmware :: Reboot not required
Storage Enclosure Firmware :: Reboot not Required
Zappa :: Reboot not Required
Pompano :: Reboot required
Tape Firmware :: Reboot not required
HDD DUP Firmware :: Reboot not required
Catfish Firmware :: Reboot not required.
Note : None of the driver update requires reboot.
Thanks,
Nitin
DELL-Pupul M
2 Intern
•
1K Posts
0
December 26th, 2012 23:00
Hi,
The above mentioned information should help. Let us know if it does. I will suggest you to use DUPs which require reboot separately in this case as your servers are becoming unreachable. OME is intelligent to take care of sequence in which the DUPs are applied and the DUPs which require ipdate are applied at last. But in a situation like this where the server is becoming unreachable on appyling an update, i will suggest you to apply updates which require reboot in a separate task and the ones which do not require reboot in a separate one.