Here is a general principle: no server really knows where it is.
Here's another one: there is no substitute for a physical visit.
OK, so in the unlikely event someone reads this and wants to disagree, let me expand slightly on those points.
In a terribly well organised network the Configuration Manager may feel that the network details (e.g. VLAN name, IP) gives the location. That is all and good in a broad-brush sort of way, but no better than that and really it is no guarantee of even haphazard accuracy levels. In a new network the IP range or VLAN name might be a good representation of something like a room in a data centre, but these waters get necessarily muddied pretty quickly. Furthermore, if the company's engineers remote build servers (and who doesn't these days?) then they may well be asked to add in some location data - but if they've never actually been to the installed box, how can they be sure that the documentation they have is correct? After all, serial numbers embedded into motherboards by manufacturers can be slightly different from the one on the case label - fresh out of the box; what hope of correct location data does e.g. SNEEP have on a SUN server?
So there we are. You can't just assume you know where kit is - and as we all know, it is terribly important that an Enterprise knows where all the kit it owns is.
UCMDB / DDMA can't just tell you where your kit is. Get discovery right and it will tell you what model the machine is and (mostly) it will tell you the serial number. As said above, you might be able to make some assumptions based on VLAN but if you want to know enough to get your engineer to walk to the server, that simply won't do.
Regarding serials, BMCs ADDM product seems more reliable than DDMA on seeing serial numbers on Fujitsu-Siemens SUN servers - and on T-Series SUN kit. On everything else (pretty much) they match each other. As long as one avoids the dreaded CSTM issue on HP-UX B.11.11. Anyhow, in the words of the late, great Frank Zappa, I digress.
Once you have the serial number and the model, it is down to the people doing the physical audits. But you can help them, and you can take the data they hold and turn it into useful information that engineers, BCP planners, capacity planners and many others can use.
I am lucky. Where I am working right now, they have an excellent and dedicated team that visits every data centre on a regular basis, recording every piece of kit they find - model, label (FX: spit - I hate labelling servers, it is just so unreliable), serial number, rack, room, building and all that. They maintain a hugely complex spreadsheet of this data.
I have added an attribute to the Node CI: 'Grid Ref'. The auditing team use a parameterised Pattern View in uCMDB called 'Find by Serial' to locate the CIs for these servers and add in the Grid Ref. Also, I have created a cascading tier of Location CIs - rooms, buildings, cities all appropriately related to each other. A server CI should have a Grid Ref value and a Membership relationship with a Location CI of Location Type 'Room'. I have also created a report that looks for servers with a grid ref but without a relationship to a Location CI. That is emailed to me by uCMDB on a regular schedule. It is then my job to add in the appropriate relationship to the Room CI.
Lastly, I have amended one of the built in location related enrichment rules to put a set of stings and values into the Calculated Location field so it reads something like this example:
"City: London; Building: Enfield Office; Room: ENF03; Grid Ref: B21"
Dead handy for reporting, that is.
Once this is all done, pick a building, pick a room, uCMDB can show you the servers in there by rack. That is useful Location information created from a lot of data. Combine that with things like Services running on a server and uCMDB can really inform users and teams.
So no server knows where it is, but there is a very good chance that for most servers in my current company's estate, uCMDB does. As it should.
