We've seen something like this in rare cases where a device has a duplicate MAC address from another device/server. Other times where a Service Tag from a server is duplicated somehow (which should be impossible). Can you review your MAC addresses for duplicates?
Verified there are no duplicates or even close duplicates for MAC addresses. When the machines are added "fresh" the resulting MACs are unique. When the second one is discovered the 2 sets of MACs both show in the list for the device. Only one record that swaps back and forth on details (except the merged NICs) as the different discovery range is run.
However, neither machine resolves a service tag number on OME, nor when I remote into the machine and try using the auto-detect feature on the dell support site. As they are fairly remote I can't physically check the machine for the service tag.
The dell site auto-detect does install and run and returns a blank for the service tag.
Just updated one to 7.3 OMSA and Chassis Service tag is still blank (PowerEdge R710 with Server 2003 R2 SE)
Well for sure use the SNMP, WMI, WSMan test for the server you are trying to discover. Of course use whichever of those protocols in the test that you are trying to manage the device with. The results of the SNMP + OMSA test, for example, might prove instructive.
What specific feature of the troubleshooting tool should I be running? Because the warranty service one asks for the ST number before you can go on and none of the rest look applicable...
We are managing via SNMP with community and server specific settings. Tripped me up as I had to run the tool from the server to get it to work (wouldn't accept SNMP requests from anything but the server nice to know that security feature is working).
SNMP came back normal with expected information
Name Resolution came back normal
Services came back normal
OMSA Remote Enablement failed due to connection error
Port test shows port 443 (for the OMSA test) wasn't open :) Pretty sure that port is closed on all our machines. But opened it on the machines in question and the server. Still no dice on that. But I checked a few other machines and it also didn't work on any of them once the ports are open. And troubleshooting tool shows ports as available on both machines and server. So maybe an unrelated issue (something stupid I am doing).
On the OMSA for each machine the Main System Chassis information is just blank for Chassis Service Tag, Express Service Code and Chassis Asset Tag. No other entries are blank.
Machines are different OS (2003 R2 SE and 2008 SE)
Issue persistent through OMSA version changes (6.2 upgraded to 7.3).
Original OMSA versions different (6.2 and 6.4)
Dell Auto-Detect tool for service tag from support website returns BLANK for both (not an error on the tool, it 'populates" the web dialogue and then it says "cannot be blank")
One is an R710, one is an R510
The Storage enclosure on each has a Service Tag Entry
One machine is fully updated via System Update (doing the other now, the fact that records swap kept making miss updates on the one)
Possibly interesting note: when using the database column filters in OME, there are entries that are "empty" for service tag, but this machine shows as a blank (attach screenshot) other 3 entries were the "empty" and the CT3 machine is the blank...
1) service tag goes to "empty" sometimes due to status updating/refresh (can't get it yet) I thought that was normal behavior for when a follow up discovery can't actually connect...
2) these 2 machines are not EMPTY as per the others (which do not cross connect like this). This service tag field IS returning some sort of data that is null or unrecognized character as it reads as a different entry in the dB than the EMPTY. Like it is a space character or something. See screen capture that shows a filter for EMPTY and a filter for " ". using the Auto-detect your service tag on Dell.com it also comes back with a sort of "blank" entry. It doesn't error like I have had some or time out or fail... it finishes it and populates the dialogue and when you click OK, it says "cannot be blank"...
3) wasn't sure about the port 443 whether it was pertinent or not. Looks like not. Configuring WSMAN for the iDRAC is down the road...
4) Website check on dell.com support shows 7.3 as the appropriate version for other 2003 boxes (was 7.1 one until a bit ago and 7.2 for 2008)
5) Yes they have OMSA installed.. hence "OMSA for each machine shows" statements...and multiple statements about OMSA versions..
Not sure if OEM motherboards will have service tag as it is a unique tag associated with Dell. Is Service tag shown in OMSA console ? If not, OME may not be able to retrieve it.
Sorry for the lack of clarity. Original Equipment from Manufacturer. Stuff that came from you. Dell stuff. No changes since it was bought, shipped and deployed.
And as noted several times, OME, OMSA, and the Dell website auto-detect service tag tool ARE retrieving SOMETHING in this field. It is NOT NULL. It is just not a readable/visible character. Maybe tab or space or paragraph return or some other weird character string. Whatever, there is clearly something in the field.
DELL-Rob C
3 Apprentice
•
2.8K Posts
0
July 10th, 2013 14:00
Hi and thanks for the post.
We've seen something like this in rare cases where a device has a duplicate MAC address from another device/server. Other times where a Service Tag from a server is duplicated somehow (which should be impossible). Can you review your MAC addresses for duplicates?
thx
Rob
Lukeal
1 Rookie
•
24 Posts
0
July 10th, 2013 14:00
Verified there are no duplicates or even close duplicates for MAC addresses. When the machines are added "fresh" the resulting MACs are unique. When the second one is discovered the 2 sets of MACs both show in the list for the device. Only one record that swaps back and forth on details (except the merged NICs) as the different discovery range is run.
However, neither machine resolves a service tag number on OME, nor when I remote into the machine and try using the auto-detect feature on the dell support site. As they are fairly remote I can't physically check the machine for the service tag.
The dell site auto-detect does install and run and returns a blank for the service tag.
Just updated one to 7.3 OMSA and Chassis Service tag is still blank (PowerEdge R710 with Server 2003 R2 SE)
DELL-Rob C
3 Apprentice
•
2.8K Posts
0
July 10th, 2013 15:00
Ok, interesting. Worried about the blank ST.
Can you run the Dell troubleshooting tool against those nodes? Let me know what results are returned.
Rob
DELL-Rob C
3 Apprentice
•
2.8K Posts
0
July 10th, 2013 16:00
Well for sure use the SNMP, WMI, WSMan test for the server you are trying to discover. Of course use whichever of those protocols in the test that you are trying to manage the device with. The results of the SNMP + OMSA test, for example, might prove instructive.
Rob
Lukeal
1 Rookie
•
24 Posts
0
July 10th, 2013 16:00
What specific feature of the troubleshooting tool should I be running? Because the warranty service one asks for the ST number before you can go on and none of the rest look applicable...
Lukeal
1 Rookie
•
24 Posts
0
July 11th, 2013 11:00
We are managing via SNMP with community and server specific settings. Tripped me up as I had to run the tool from the server to get it to work (wouldn't accept SNMP requests from anything but the server nice to know that security feature is working).
SNMP came back normal with expected information
Name Resolution came back normal
Services came back normal
OMSA Remote Enablement failed due to connection error
Port test shows port 443 (for the OMSA test) wasn't open :) Pretty sure that port is closed on all our machines. But opened it on the machines in question and the server. Still no dice on that. But I checked a few other machines and it also didn't work on any of them once the ports are open. And troubleshooting tool shows ports as available on both machines and server. So maybe an unrelated issue (something stupid I am doing).
On the OMSA for each machine the Main System Chassis information is just blank for Chassis Service Tag, Express Service Code and Chassis Asset Tag. No other entries are blank.
Machines are different OS (2003 R2 SE and 2008 SE)
Issue persistent through OMSA version changes (6.2 upgraded to 7.3).
Original OMSA versions different (6.2 and 6.4)
Dell Auto-Detect tool for service tag from support website returns BLANK for both (not an error on the tool, it 'populates" the web dialogue and then it says "cannot be blank")
One is an R710, one is an R510
The Storage enclosure on each has a Service Tag Entry
One machine is fully updated via System Update (doing the other now, the fact that records swap kept making miss updates on the one)
Possibly interesting note: when using the database column filters in OME, there are entries that are "empty" for service tag, but this machine shows as a blank (attach screenshot) other 3 entries were the "empty" and the CT3 machine is the blank...
DELL-Raj S
327 Posts
0
July 11th, 2013 13:00
ServiceTag should never be empty. Couple of things to clarify:
Port 443 is used for discovery of iDRAC and ESXi servers using WSMAN protocol.
For SNMP, port 161 should be opened on the managed servers (with OMSA installed) for OME to discover these servers.
WIndows 2003 may not be officially supported in later versions of OMSA 7.x.
Are the servers being discovered using SNMP protocol ?
Does all these servers have OMSA installed ?
Was motherboards replaced on these servers ?
Recommended to discover iDRAC 6 and 7 using WSMAN protocol and secure mode enabled in OME discovery wizard.
Thanks,
Raj Shresta
Lukeal
1 Rookie
•
24 Posts
0
July 11th, 2013 15:00
1) service tag goes to "empty" sometimes due to status updating/refresh (can't get it yet) I thought that was normal behavior for when a follow up discovery can't actually connect...
2) these 2 machines are not EMPTY as per the others (which do not cross connect like this). This service tag field IS returning some sort of data that is null or unrecognized character as it reads as a different entry in the dB than the EMPTY. Like it is a space character or something. See screen capture that shows a filter for EMPTY and a filter for " ". using the Auto-detect your service tag on Dell.com it also comes back with a sort of "blank" entry. It doesn't error like I have had some or time out or fail... it finishes it and populates the dialogue and when you click OK, it says "cannot be blank"...
3) wasn't sure about the port 443 whether it was pertinent or not. Looks like not. Configuring WSMAN for the iDRAC is down the road...
4) Website check on dell.com support shows 7.3 as the appropriate version for other 2003 boxes (was 7.1 one until a bit ago and 7.2 for 2008)
5) Yes they have OMSA installed.. hence "OMSA for each machine shows" statements...and multiple statements about OMSA versions..
6) Definitely not. motherboards are OEM.
DELL-Raj S
327 Posts
0
July 12th, 2013 15:00
Not sure if OEM motherboards will have service tag as it is a unique tag associated with Dell. Is Service tag shown in OMSA console ? If not, OME may not be able to retrieve it.
Lukeal
1 Rookie
•
24 Posts
0
July 15th, 2013 09:00
Sorry for the lack of clarity. Original Equipment from Manufacturer. Stuff that came from you. Dell stuff. No changes since it was bought, shipped and deployed.
And as noted several times, OME, OMSA, and the Dell website auto-detect service tag tool ARE retrieving SOMETHING in this field. It is NOT NULL. It is just not a readable/visible character. Maybe tab or space or paragraph return or some other weird character string. Whatever, there is clearly something in the field.