When I try to export a displayed report to a disk file, I cannot save it to any Windows network file share. For example, if I try to save it to My Documents which is mapped to a network location, I get an error that My Documents could not be found. The same thing happens with any network location. The program only seems to recognize the local machine's disks. This is extremely inconvenient.
How can I reconfigure it to recognize network file share locations? Do I have to change something on the CCX server? Thanks!
Thank you for the reply. Unfortunately, that setting is of no help & in fact appears to be some sort of 'urban legend' in this forum as a proposed solution. But it is not so!
Cisco has allowed this bug, which you cite by number (CSCse79713) to languish since 2008. That's 3 years. It actually appears to be a design flaw. in the Historical Reporting software. Here is what appears to be going on:
First of the all, the software installation has the audacity to silently install a local user account with administrative privileges on the PC user's Windows machine. This is a nasty security risk!
Next, the Historical Reporting software appears to use that local user account to run, save, and print the reports. Hence the 'real' PC user & domain member is given no access to Active Directory domain network resources like file shares or printers, since it's done as a 'run as' the Cisco created LOCAL account.
I am new to the CCX system & very disappointed in the difficulty in getting this important tool to work well in a typical Windows AD domain environment.
have you been able to resolve this issue? Cisco claims this is the patch to resolve this - 7.0(1)SR01_ES03, but I cannot find this patch anywhere.
The workaround didnt work for me either - even though the issue i am concerned with more is with the scheduler not working.
There has been no response from Cisco or anyone else on this issue as of today. In any event, a 7.x patch would not help me as my CCX Historical Reports client version is 8.0(2.5). I agree this is quite an annoyance and should be addressed.
I came to similar conclusions I think - I think the need for a local account appeared to be to enable use of passthrough credentials to authenticate to the CCX server, which was off domain.
Since we're now on a Linux server there can be pretty much no reason for that local account to exist.
The only workaround I'm aware of is to:
1) Run the scheduled report so that it exports to a local directory (e.g. c:\reports)
2) Set up a scheduled task that runs with a domain account; this task would run a simple cmd script to move the files to the required location on the network.
Please rate helpful posts...
Thanks for the workaround suggestion, Aaron. Your workaround idea would work, but it is a lot of extra trouble to have to go through to save report output files on a network file share. That's a pretty common practice in most organizations and Cisco should support it. The reason they are not yet supporting it probably has to do with that 'secret' local administrator user the Historical Reports installation sets up on the PC. Those local credentials would not have network share access. A much better plan would have been to let the user opt to use Active Directory domain credentials instead at install time. The AD credentials would likely have write access to one or more network file shares.
Of course... but we aren't in a position to fix that for Cisco. The best you'll get here is an offere of a workaround.
As a customer you should raise a case with Cisco and get your Cisco Accounts team to chase up a fix. I'm not sure how much drive there is to fix things like this though as CUIC looks like where all the effort is going now...
If you are interested - there are 3rd party reporting applications that easily can accomplish what you are looking to do. Please contact me for more information.