Setup CDR to save CSV on shared network

[Randall Garner]

I am attempting to setup creating of CDR to CSV format on a shared network folder. However, I'm not able to get the CDR created at all. I've reviewed the steps found in the manual and online, but still no luck. Can someone please provide me with a summary of steps to create CDR to CSV?

 

We are running 2011-4.2.1.4025 (Win64).

 

Thanks,

 

Randall

[pbx support]

http://wiki.snomone.com/index.php?title=Call_Detail_Records_(CDRs) explains different types of CDR destination. The one you are interested is

 

file:f:/cdrs/$d-$h.csv

 

The above value in the CDR URL will save the date-hour.csv file under f:/cdrs folder, where f is the shared network drive.

[Randall Garner]

Yesterday I applied the exact command provided, except changed the mapped drive letter to match my setup, but this morning found no file is getting created.

 

What else should I look at to get this feature working?

 

Thanks!

[pbx support]

Do you have a 'cdrs' folder on that drive and permission to create files on that folder? Other than that you do not need anything else.

[Randall Garner]

Good morning,

 

I have verified the CDRS folder was created on the mapped network drive, and verified the PBX has permissions to create files on the mapped network drive as well. However, we did NOT get any CDRs created all weekend.

 

What other settings in the PBX should we check to get the CDR CSV created?

 

Thanks,

 

Randall

[pbx support]

As long as the PBX has access to the drive/folder, the files should be created there.

[Randall Garner]

I understand what it should be doing, but it's not, thus the reason I contacted support.

 

To review what we have confirmed -

 

In the snomPBX, Admin, Settings, Appearance, CDR URL = file:l:/cdrs/$d-$h.csv (settings provided in this post to create the CSV file)

 

In Windows on the PBX, open Windows Explorer, can open the l:\ mapped drive, can open the "cdrs" folder, and can create files and folders in the l:\cdrs folder (this confirms the PBX has rights to create files in this drive/folder.

 

However, there are no CSV files getting created.

 

Are there any other settings to look into? Are there better tests I should perform to verify correct paths and permissions? I hoped this forum would be more helpful than the last post.

 

Thanks again for your help,

 

Randall

[pbx support]

Well, the PBX will be running under the "SYSTEM" account. That may not have permission to write the file on the shared folder.

 

Do you see any error on the PBX log, like the one below?

[0] 2012/07/16 13:55:18:	Could not open s:\cdrs\20120716-13.csv for writing

[Randall Garner]

I do have the error you're looking for -

 

2012/07/16 14:57:07: Could not open L:\CDRS\20120716-14.csv for writing

 

I believe your theory about the PBX running under SYSTEM account is correct. Can we change the account the PBX runs under?

[pbx support]

PBX really have to run under the admin/system account.

The easy thing to do is to change the permission on the shared folder to give write access to remote users.

[shopcomputer]

Don't use mapped drive use UNC, as drive mappings are user specific.

[Randall Garner]

Thanks for the post, shopcomputer!

 

I can map network drives with the correct user permissions, however, it is the SYSTEM account creating the CSV which does not have permission on the Active Directory domain (the PBX is not part of the domain). This is why my file isn't getting created.

 

I thought about UNC paths, but it was not documented and not suggested by support, so didn't try them. However, I don't believe this would have made any difference with my issue - the share and NTFS permissions are still applied at the shared folder, which would still not allow the non-AD PBX to write to that location anyway.

 

Again, thanks for taking the time to post!

 

Randall

[pbx support]

Not sure what the problem there. We are able to write to a shared drive (which is on a remote system) with the syntax we discussed earlier.

[Randall Garner]

We've figured out our problem. My last post was simply to reply to shopcomputer the additional information we knew and thanking them for help.