With great difficulty
The database isn't a flat file, so you can't export the whole thing to Excel.
You can retrieve each table, so if you check out the database schema you can retrieve any table like so:
1) Connect to the server with SSH using Putty or another SSH client
2) Set the SSH client to log to a text file
3) Run a command like so:
Run sql select * from enduser
4) Close the SSH client
5) Import the text log to Excel as a text file, using the wizard to set the delimiters
A lot of the tables will contain references to the other tables, so each table on it's own may not mean very much.
What exactly do you want to do with the data? Someone may be able to offer you a more practical suggestion...
Please rate helpful posts...s
I believe you may be thinking of the BAT export. You can use BAT export in CUCM 7x to export a number of configurations to a TAR file. That TAR file contains the data in CSV format which you can then use to open up in Excel.
Please rate helpful posts!
Actually, you can use the import/export utility to get what you want out of CUCM. The flat file will not work. You could try and run DRS and then open up the files after the backup, but if they are anything like the TAR files from upgrade utility, it is a ton and ton of CSV files.
Import/export is nice. It grabs the raw data from the database and spits out to excel. You can use a program (or what I use) is 7-zip I think its called. Free and works perfect for CUCM.
just as a side note here - starting with version 8 of the platform, DRS has started encrypting the TAR output files (all of them from all clients including call manager and Unity connection). They cannot be unencrypted, only fed back to DRS for restore purposes (i.e. they aren't exposing their encryption technique to anyone, even for internal tools such as my DRS Message Fisher). This will thwart attempts to get at the CSV files in those backups unfortunately.
They are supposedly working on a way for tools developers such as myself to get into the TAR files provided the user enters the platform login/PW and can connect to the platform server (i.e. you can get a key to unencrypt the TAR file from their web service). I think they're shooting for 8.5 for that but I'm not sure it's comitted.
just so ya know...
lindborg wrote:They are supposedly working on a way for tools developers such as myself to get into the TAR files provided the user enters the platform login/PW and can connect to the platform server (i.e. you can get a key to unencrypt the TAR file from their web service). I think they're shooting for 8.5 for that but I'm not sure it's comitted.
Did this ever happen ?
No, it never did - the "ask" for the DRS folks to provide unencryption capabilities for their TARs is still out there (several other BUs want this) but so far as I know there's been zero movement on it. I've about given up hope on the DRS folks at this point - pretty clear this isn't a priority for them and I don't see much in the way of any kind of improvements on the product schedule for them at all, this included.
As a side note I've been pushing the Connection product managers to give us off box file system access to limited directories via a proxy service and roles (i.e. similiar to the ODBC proxy but for SFTP access) - armed with this we can provide our own (far superior) disaster recovery tools that work on a pull model instead of the full push DRS is built on - this would get partial backups, individual restores, about 6x increase in performance (more actually - I have a prototype that is hovering right around 10x the speed of DRS end to end), smaller backups, requires less space and resources on the server etc... etc... Fun stuff like doing a full backup on Sunday mornings and deltas every day of the week after that and another full backup Sunday etc... would be possible. Imagine.
I'll probably get more traction with that but it's a long road I'm afraid - as ever, asking your account team to enter a PERs helps - makes it more difficult for the product folks to delay on assigning engineering resources to such efforts.
They don't even need to write a tool, as a first off. All they need to do it document the encryption algorthym(s) so we can use existing tools to do the decryption.
Well, their argument there is once the decryption logic is in the wild there is no longer any encryption.
The plan was to provide "one off" descryption passes via a web service (i.e. temporary PW that work for a limited period on a specific client MAC for opening a specific TAR file build from that Connection server) - somewhat more secure but a pretty good pile of work and of course it's not backwards compatible.