Unsolved
This post is more than 5 years old
3 Posts
0
59081
What Happened To "schemas.dell.com"?
If you google "schemas.dell.com" you'll see that the domain is referenced in countless Dell articles. The web site was home to CIM schema definitions for all Dell equipment. The domain no longer resolves. Does anyone know what happened but, more importantly, how do you use the CIM commands without a reference to the schemas?
DELL-Geoff P
990 Posts
0
February 12th, 2014 13:00
Binaryagent,
You may want to check out this site for schemas:
binaryagent
3 Posts
0
February 12th, 2014 14:00
We have several M1000e chassis' and I want to pull an inventory with Powershell.
Dell has published several articles referencing the domain. They need to either fix the domain or publish corrections for the articles.
DELL-Geoff P
990 Posts
2
March 17th, 2014 15:00
Here is what the customer came up with as a solution:
Finally figured out how to query the Dell blade chassis and pull an inventory with Powershell. Now we can programmatically inventory all our Dell blades and reconcile against Solarwinds, etc.
$ipaddress = "msdellch01"
$cimop=New-CimSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck -Encoding Utf8 -UseSsl
$session = New-CimSession -Authentication Basic -Credential $cred -ComputerName $IPAddress -Port 443 -SessionOption $cimop
$bladeinfo = Get-CimInstance -CimSession $session -ResourceUri "http:// schemas.dmtf.org/wbem/wscim/1/cim-schema/2/root/dcim/DCIM_BladeServerView" -Namespace root/dell/cmc
$bladeinfo | ft HostName,BIOSVersion,IPv4Address,Model,SlotNumber
mharlan
2 Posts
0
March 17th, 2014 15:00
I'd like to see an answer to this too -- schemas.dell.com is needed for Powershell scripting of M1000e chassis.
mharlan
2 Posts
0
March 17th, 2014 15:00
That worked! Thank you so much!!
binaryagent
3 Posts
1
March 18th, 2014 06:00
Here's some additional info on this issue:
So if you browse the website in the URI provided, you can only drill down as far as “/wbem/wscim/1/cim-schema/2/”. There is no “root” folder beneath there. Or at least it’s not “browsable”. So I cranked up Wireshark to see what data is actually being transmitted when you run the command that references the URI. I didn’t see much of anything. So then I tried some variations of the known good URI:
Working that you sent:
http://schemas.dmt f.org/wbem/wscim/1/cim-schema/2/root/dcim/DCIM_SystemView
Also working:
http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/DCIM_SystemView
http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/dcim/DCIM_SystemView
http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/foo/DCIM_SystemView
You’ll notice that I was able to remove the “dcim” and “root” from the path and it still worked. Beyond that (remove the “2”) and it won’t work. Then I added “foo” and it still worked!
So in the get-ciminstance help I found this:
A URI consists of a prefix and a path to a resource. For example:
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_LogicalDisk
http://intel.com/wbem/wscim/1/amt-schema/1/AMT_GeneralSettings
By default, if you do not specify this parameter, the DMTF standard resource URI
http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/ is used and the class name is appended to it.
So the last part sort of explains why the malformed URI’s still work.
Also, the Namespace parameter "root/dell/cmc" doesn't seem to be required for this to work.