64-bit Windows SUU availability

Hi Zinc666

There is an issue with the latest Broadcom Firmware update running on a 64bit OS.  Broadcom is working on resolving this issue and will have a corrected version available in December that will be available both via support.dell.com and through Dell Repository Manager.

As you correctly pointed out, you were able to install it using Lifecycle Controller which is an out of band method of installing BIOS & Firmware.  Another method is to use Dell Repository Manager and create a Bootable iso.  The advantage of a bootable iso is that it can be run on 9th Generation systems (like PE2950) all the way up to the most current systems (like R320).

Ray

addilapi,

Thank you for taking the time to carefully outline your frustration points.  I will work with my teams to address your concerns, and create a more clear message about when to use a 32bit Windows bundle vs. the 64bit Windows bundle.

I agree v480 on SUU should be identical to v480 on the FTP Catalog that Repository Manager uses.

Dell releases update packages between the quarterly SUU release, hence why the FTP Catalog that Repository manager uses is updated more frequently so that there is access to these updates.  The Server FTP Catalog is updated on a monthly basis, however if an important update is released we will update the catalog to pick it up.

Again, I appreciate your comments and will do my best to address them.

Ray

Yes, I agree the latest 7.3.1 SUU release seems to be completely botched.  Here is my experience;

1. Only the 32-bit version was released... no 64-bit this month?  I don't know why since if you use Repository Manager there are clearly still separate 32-bit and 64-bit Windows bundles.  The 7.3.1 SUU ISO only contains the 32-bit bundles though and the 64-bit bundles are MIA.

2.  This is the really really bad one... the 7.3.1 SUU ISO was released with bundles that are reported as v480.  However, Dell Repository Manager also lists v480 bundles available for download from the FTP site BUT THEY ARE NOT THE SAME.  The ISO has much newer components in its v480 bundles than repository manager has.  Since Repository Manager, Lifecycle Controller, vSphere Integration, etc. all download their bundles from the FTP 'master' but the ISO has totally different firmware/driver versions you might think you have updated all servers to v480 (aka Dell Support 'tested' firmware/driver bundles) but in reality you could have the same model system with different components installed if you use different update sources!

This setup really needs to be fixed.  Historically one of Dell's strengths was the quarterly release of well-tested system components.  More recently this has fallen by the wayside (starting with the introduction of Repository Manager and getting worse over time) where now we get incremental repository updates every few days (with no change in bundle versions), incremental bundle updates (v470 being a quarterly release but then followed by v472, v474, etc), and completely mismatched bundle versions (v480 on the ISO vs. v480 on the FTP... and the FTP one changes every week).  There has also been a lot of confusion created by the separation of 32-bt vs. 64-bit Windows bundles (why do I need to apply both to a 64-bit server?  can't you make a single bundle for my server?), the inclusion of OpenManage and/or Driver Packages in some bundle versions but not others, and problems like the Broadcom firmware where OME says we are always out of compliance because the firmware version number inventoried is different than the version number Dell says it is installing!

Very frustrating... please go back to consistent, well-tested bundles.

I am again having problems with the latest Dell System Bundle Catalogs for PowerEdge T320 (Version PHA182A.484).  How can I get support on these Dell provided System Bundles including posting bugs (like the fact that the Broadcom NIC drivers are now missing from the bundle)?  Last month the NIC driver was included in the v482 bundle catalog but Repository Manager mysteriously would not download it... and every more mysteriously would not report that as an error even though every update mechanism would then choke on the fact that the package was missing... (until it was downloaded manually and added to the repository folder...)

Further update on this... I tried last night to repair the "broken" Dell v484 PET320 bundle but ran into another problem I've been seeing... missing updates on the Dell Support site.  In this case the Broadcom FIRMWARE included in the v484 release (7.6.15) says it works best with the Broadcom 17.6.0 DRIVER (which is what is missing from the Bundle).  A trip to the Dell Support site reveals that the Broadcom 17.6.0 DUP is ... missing.  There is a 17.8.4 (newer) DUP available at http://www.dell.com/support/drivers/us/en/555/DriverDetails/Product/poweredge-t320?driverId=7TH1H&fileId=3325762022&osCode=WS8R2&languageCode=EN&categoryId=NI# but when you click on the Previous Versions and go back to 17.6.0 there is no DUP anymore... just a download for some DOS utilities.

I know that this DUP used to be available since I had to manually download it just a couple of weeks ago for some other troubleshooting I was doing with Dell updates.

Where did the older DUP go?  Why is the quality control on these Bundles so bad?  This does not give me confidence in Dell's server systems these days.  Does anyone know if HP does better with their firmware/driver releases?

In the past week or so Dell has stealthily released a Catalog update that didn't change a version number (still v484) but now includes the 17.8.4 Broadcom driver.

While I'm glad the problem is at least partially addressed I continue to be frustrated over the lack of transparency from Dell (no announcement of this release, no response on the forums, NO VERSION CHANGE?? in the catalog???????)

Please, someone at Dell take a look at these release procedures and the product you are delivering to customers.  And reflect upon how long customers will stick with you given the long-term downhill slide of DUP / SUU / Catalog release quality...

Great question Jim and one that puzzles me also?

Shall eagerly await the answer...

Thx,

JB

Ray,

I am trying to figure out how the new 64-bit bundles apply to my environment. If I download both, the 32 bit bundle for most systems is ~ 1.2GB while the 64 bit bundle is ~ 450MB. If I am running a 64 bit OS, do I need to run BOTH bundles for a complete update? I see that if I use the 64 bit version, some updates are missing, so I assume it is not a complete pkg on its own. If I run the 32 bit version, does this install 32 bit network drivers?? How do I "blend" the updates to get a full refresh of firmware and software drivers.

I have spoken to Dell Support via email but never got a coherent answer. Thanks.

Jim

Hi Jim,

Device Vendors are continuing to roll out native 64bit update packages.  Hence why there are fewer of them than their 32bit counterpart.  The coverage continues to grow and over time will become equivalent.  However there are instances where only the Microsoft Windows 64bit are usable.  To date this is only with Windows 2012 Core Edition (the very stripped down version of Win Server). 

The good news is that Microsoft Server 64bit Operating Systems continues to be able to utilize 32bit updates.  It can do this because a little application called WOW64 continues to be installed with each version of Microsoft Server (with the exception of Win Server 2012 Core as mentioned above).

Thus, when in doubt utilize the Win 32bit Bundles and updates, as you have in the past.

Q: Why didn't you just combine both 32 and 64bit Windows Server updates together in a single package? 

A:  To do so in the Windows Server World would have doubled the size of the package.

Q:  In Linux you have both 32 and 64 in one package.

A:  How Linux is structured the addition of the two in a single package is a minimal additional size package.  Thus, easier to accomodate.

Ray,

Much appreciated! I don't know why this was such a challenge for support to answer. I'll stick with the 32 bit for now (until I need to deploy Core).

Jim

It has been a bit rare in the last few quarters but I occasionally come across a DUP that will not install from SUU 32-bit.  For that reason I've adopted as a best practice in my organization the application of 64-bit SUU followed by 32-bit SUU.  For example, I use the following PowerShell code snipped during first logon following imaging (this runs well with or without WOW64):

$Credential = Get-Credential

            ForEach ($Architecture In (64,32))
            {
                New-PSDrive -Name Z -PSProvider FileSystem -Root "\\SERVER\Dell $Architecture-Bit" -Credential $Credential -Persist

                Write-Host "Running Dell Server Update Utility ($Architecture-bit)..."
                Start-Process 'Z:\SUU.cmd' -ArgumentList "-update -directory `"$((New-Item -Path "C:\Initial Configuration\SUU$Architecture" -ItemType Directory -Force).FullName)`"" -Wait
       
                Remove-PSDrive -Name Z
            }

Using New-PSDrive and Remove-PSDrive are not generally needed if you want to adapt this code to your own environment and will be running under an account that has access to your shared SUU directories.  Mine is setup that way since the initial logon is performed under a non-domain account and I need to map the drive (with domain credentials) in order to access SUU.