I ran into a very strange issue today when I went to redeploy an old Proliant DL380 G5. The first thing I did was use the most current service pack DVD to update the firmware. The most current is from 2/2014 and has the number 2013.02.0. After installing ESXi 5.1 U1 I noticed that I was only showing 4 NICs and not the 6 I started with.
The two embedded NICs were missing!!
After a quick google search or twelve I stumbled upon an HP discussion with exactly the same problem that I was having. I followed the instructions from the HP discussion and here is what it took to fix (Most of this is copied from user hase3d’s post).
1. Download all necessary tools
– download FreeDOS
– download XDIAG.exe
– download bc08c740.bin
– read all information in setup.txt
2. Prepare the FreeDOS.iso
-After downloading open the iso with a tool like UltraISO. I used Magic ISO.
-Add the XDIAG.exe and the bc08c740.bin to the iso – I these files to the root so that I wouldn’t need to add a path later.
-Save the iso with a new name.
-Burn it or mount it with ilo.
3. Boot from FreeDOS
-Select Install to harddisk
-Select your language and press Enter
-Select run FreeDOS from CD-ROM
4. Mine booted to f:\freedos. Do a cd\ to get back to the root of f:
5. Run xdiag in engineering mode by typing xdiag -b06eng
6. type device 1
7. nvm fill 0 0x600 0
8. nvm upgrade -bc bc08c740.bin
9. nvm cfg
-Press q again
-Type 16=10 wich sets the BAR size to 32
-Press q for the third time
-Type save and then exit out to the main menu
10. Type device 2 and repeat steps 7-9, run the command 1=00:00:18:xx:xx:xx <— change the last digit for different mac on device 2.
I did not do anything else from the setup.txt file.
I powered down the host and then when I rebooted I had 6 NICs again!
I came in this morning only to be greeted by my web client telling me that I can’t login because it can’t create SAML 2.0. I am not sure that I really want it creating SAML 2.0….I don’t know SAML 1.0. Ok, bad joke. Here was the message…
I found KB2034798 at which point I remoted into my SSO server and checked the imsTrace.log for “NetUserGetLocalGroups”. I didn’t find it…so the KB didn’t apply to me…L
After some more googling I found this blog post that indicated that references KB2043070. The idea is that there is a local identity source within SSO that it is trying to authenticate the users to. You have to login with the admin@system-domain account and password. Hopefully you saved this when setting up your SSO server. The only problem I had was that I didn’t have this local identity source to remove.
I thought to myself, that there might be a stale identity source on the list that it is authenticating to. I was talking to a coworker and they mentioned that there was a domain that was deleted the day before. AHAH!! I clicked on the identity source of the domain that had been removed and then clicked “Test Connection”. There was an error that didn’t tell me much.
I cancelled out and was back at my list of identity sources. I selected the identity source that had been removed from AD and I hit the red X, “Delete Identity Source”. You will get a prompt asking for you to confirm. One thing to note is that the identity source that I deleted was not one of the default domains at the bottom. If you haven’t set a default domain up, I would do that now. I am wondering if there might be a bug that uses the identity source at the top of the list instead of the default at the bottom. After deleting the state Identity Source I was able to login again.