This post is more than 5 years old
44 Posts
0
169483
Platform Update: FTP or SUU/USB
I have a brand new R310 and I wanted to run Platform Update before installing Windows OS. I have the iDrac Enterprise, so I guess I should be able to do this using FTP in USC, but the process stalls.
When I attepmt to test the network connection, the 3 first tests succeed, but the final test, where it attempts to ping the ftp server fails. If I ignore this and just try to run the update anyway, I first get a message "Please Wait" for a few seconds, then "Connecting to FTP" for about 10 seconds, then "Downloading the Catalog" for hours and then eventually (the next day) it gives up.
I am guessing it has to do with our proxy/firewall setup. (Curiously, I am not sure if I have to include the domain-name with the proxy username, like this: domain\user, and I can't try it out because the backslash character doesn't work in USC with a danish keyboard. Neither do any of the other characters usually accessible with the Alt-Gr key or Ctrl-alt key-combination - like '@' or '$' - very strange).
I had kind of given up on getting FTP to work because I don't want to mess with the proxy server, so my plan was to just download SUU and get that onto a USB stick and let Platform Update work from there. But now I am a bit confused about whether I can expect the updates from the 4 downloaded SUU 6.5.3 isos to be as new as those Platform Update can pull directly off the FTP site. Can somebody shed light on this?
Off course I would also be happy to get advice that can help me get FTP to work. I am leaving Address, User Name, Password and Catalog Location unchanged and I am filling out all the proxy-related settings: Server, Port, User Name and Password. I leave Type to HTTP. The proxy server is a Windows Small Business Server 2003 (so ISA 2004 I think) - soon to be retired. And there is also a hardware firewall outside of that. I am able to get on ftp.dell.com with Windows Explorer and download files from normal doamin-machines while logged on with a domain account, but not really when logged on with a non-domain account (I get some warning message and the Windows Explorer switches to Intenet Explorer, which presents a web-view of the FTP-site.)
DELL-Rey G
3 Apprentice
3 Apprentice
•
898 Posts
1
April 5th, 2012 13:00
To answer your original question, the ftp catalog is "usually" at the same state as the latest SUU. There are exceptions to this, but they should be rare. Using SUU as the repository is easier if you have problems connecting to the ftp site. At this time, the ftp catalog has later versions of the bios for 11th generation systems. An updated SUU (7.0) is scheduled to be released later this month and the catalog is going to be updated to match. if you would like, you can burn the SUU iso to disc and feed that directly to the USC platform update function. You can also extract the iso files to a USB key (need 8GB key) and present that to the USC. An alternate method is to use repository manager (which uses the ftp catalog) to create an SUU disc or directory. This is a video of RM and you can see how it would work. The RM interface has changed a bit, but you can get the drift.
Rm installer: www.dell.com/.../DriverFileFormats
DELL-Chris H
Moderator
Moderator
•
8.4K Posts
0
April 5th, 2012 09:00
Tisraelsen,
The SUU will be current up to 7/29/11. I would suggest running it and then checking to see if there are any other updates needed. Here is the link to the most current version -
www.dell.com/.../DriverFileFormats
DELL-Chris H
Moderator
Moderator
•
8.4K Posts
0
April 5th, 2012 11:00
That is fine, the procedure you are doing is just taking the repository of updates from the SUU and running them through USC, not the ISO. With the ISO you can update in the OS. With the repository you will go to the USC and run it.
tisraelsen
44 Posts
0
April 5th, 2012 11:00
Chris,
Thanks for answering.
A bit confused now... I was planning to use this method:
<ADMIN NOTE: Broken link has been removed from this post by Dell>
For that I found the SUU here:
www.dell.com/.../DriverFileFormats
No really sure what the difference is between the two, but at least this seems to be newer (v. 6.5.3 vs 6.5.1. and dated 2/6/12).
My main question was whether there is a difference between how up-to-date these downloads are compared to letting the Platform Update system in the servers Lifecycle Controller fetch stuff from the FTP site itself. I want to know that in order to determine whether to just go ahead with downloading and updating from USB or whether I should work on getting the FTP-stuff to work.
Thomas
tisraelsen
44 Posts
0
April 8th, 2012 06:00
@Rey G:
Thanks for this. I guess I was hoping to avoid repository maneger as I read another post which indicated that it is a bit of a hassle to work with, but the video really helped.
In fact i took a chance and skipped a step. After having created a new Repository with everything for R310 and R510 as weel as all of the "additional components". My intention was then to do as you describe and build an SUU structure from that to feed to Platform Update, but I kept getting strange warnings about mismatches/incompatibilities. Partly on a whim and partly based on some language in the USC-LCE User Guide about repositories, I tried simply pointing Platform Update (using CIFS Share) at the Repository folder I had created with Repository Manager - completely bypassing the step of creating an SUU structure.
It worked like a charm and I was able to update those few components which were not up-to-date.
However (brings me to my question):
I've now installed my OS and put OMSA 7.0 on the system and am able to inventory the system with OME 1.0.1. Going to System Update in OME reports that the firmware for the 2 broadcom cards is out of date: OME reports the installed firmware as 6.2.16 and reports that 6.4.5 is available.
Why was this not found by Platform Update?
Going back to Platform Update now it still reports that 6.2.16 is fine. Nothing newer available. I double checked the repository that Platform Update looks at, and Repository Manger says that the precise DUP that OME wants to apply is in fact in that repository: NETW_FRMW_WIN_R319248.EXE.
A few screenshots below:
Can you shed some light on what is going on?
Thomas
DELL-Rey G
3 Apprentice
3 Apprentice
•
898 Posts
0
April 9th, 2012 11:00
Excellent catch, and I see the same thing on this end, so its not something you are doing wrong. I am reviewing this with the Repository Manager and OME teams to understand why there are different results with supposedly the same catalog.
bradje1
743 Posts
0
April 9th, 2012 15:00
This is an excellent How To on updating your Dell servers....And it works too!!
lonesysadmin.net/.../the-easiest-way-to-update-a-dell-servers-firmware
John Bradshaw
DELL-Rey G
3 Apprentice
3 Apprentice
•
898 Posts
0
April 10th, 2012 16:00
Ok Thomas, I have been given the answers to your question. Repository Manager works by utilizing the catalog.cab file posted at ftp.dell.com/catalog. it uses this as the law for what is applicable to what system. In the case of NETW_FRMW_WIN_R319248.EXE, when it was promoted to the catalog, a couple of blade platforms were selected as being applicable systems for this dup, but that was it. In the case of OME, it uses what is in the catalog AND a list of devices the system reports back to OME via an Inventory Collector. So OME is more intelligent in this case and shows you that the nic dup is applicable because the Inventory Collector said the nic device was there. As the catalog is revised later the month, RM should then also list the next version of the dup as applicable to your systems, which should match with OME.