I am trying to schedule a report and save the report is a particular file location. So I scheduled the report and in Destination\File Location i gave the path where to store, but when I do this my report fails and the error it gives is 'source file error. CrystalEnterprise.DiskUnmanaged: Invalid argument '.
Can someone help me.
Thnx
santhana 
(BOB member since 2005-04-05)
Is the Unmanaged Disk location enabled? To check, go to the CMC Home → Servers and select the appropriate Job Server (Webi or Crystal), select the “Destinations” tab, and then configure and enable the “Unmanaged Disk” destination.
I’ve attached a screenshot for reference…
DJ
Unmanaged Disk - screenshot.zip (23.0 KB)
DJ06482 (BOB member since 2002-11-22)
I am having the same error. I have enabled the unmanaged disk and I have used a username and password that is a Domain Admin account. Using the account I can access the share I want tot copy the PDF output to with no problem. If I schedule the output to a local drive (on the XI server), it creates and saves the PDF properly. The arguments do not change when I run the report. Any ideas?
dhansen@hansenconsulting. (BOB member since 2004-11-30)
We are facing the same issue too. The Disk Unmanaged option is enabled.
And our existing weekly and some daily Webi reports failed for the last 2 days due to this error. And these are not new reports, they are all existing reports that has been generating for the last 1 year or so.
But when we try to re-submit the report at a later time, varies from 5 mins - an hour, surprisingly all the reports completed sucessfully, without any modification.
What could have causes this error? Appreciate any help on this issue.
regards,
Joyce C
joycec (BOB member since 2007-05-07)
We’re seeing the same thing here with BOXI R3. We had 13 reports run this morning and one failed with that error. Running the report manually worked just fine; they are all configured identically.
Has anyone sorted this one out yet or contacted SAP/BO about it?
jfischer (BOB member since 2008-06-25)
Hi all,
We are facing the same error as you…
There were no Issue during 2 months. We just installed the SP4 (BO XI R2) on last Friday, and now it’s the second day that this error occurs…
Any Idea ? Run something wrong with the SP4 ???
phiolu
philou80 (BOB member since 2008-06-23)
It’s not SP3 as I’m having the same issue.
mnkmarr (BOB member since 2003-10-22)
[quote:520f075f3a=“dhansen@hansenconsulting.”]I am having the same error. I have enabled the unmanaged disk and I have used a username and password that is a Domain Admin account. Using the account I can access the share I want tot copy the PDF output to with no problem. If I schedule the output to a local drive (on the XI server), it creates and saves the PDF properly. The arguments do not change when I run the report. Any ideas?
[/quote]
Your job server probably is running under a local account - use a domain account instead.
newgun (BOB member since 2007-08-01)
We solved this issue in our environment. It has something to do with the server name. In our case, the UNC path to the Unmanaged Disk had the servername:
\ServerName\folder1\subfolder1\subsubfolder1a\subsubfolder1b.
To fix this problem, we used the “IP Address” in lieu of the “ServerName”.
Ex: \101.102.129.11\folder1\subfolder1\subsubfolder1a\subsubfolder1b
Try the above recommendation and see if it works on your end.
-Ferdie
Fernand_DaCien (BOB member since 2006-05-06)
Sounds to me that your company’s DNS/WINS are having problems that need to be fixed. If you use IP address as a work around, it will break once they move the server to another IP address (doesn’t happen often but it does happen).
newgun (BOB member since 2007-08-01)
I forgot to mention that the Unmanaged Disk is not within our domain.
And, yes, this scenario has been discussed with our clients because we had the same issue with one of our Aerospace clients.
FYI- our internal users here in the U.S. still use the \Servername… without any issues. The only issue is when the Unmanaged Disk is outside our DMZ.
i.e.
BOXI Enterprise Servers : Los Angeles, CA USA
External Clients Unmanaged Disk locations: Connecticut, Alabama, Florida
and overseas, such as: Canada, Singapore, & 3 countries in Europe
-Ferdie
Fernand_DaCien (BOB member since 2006-05-06)
I ran into this problem in BOXI Rel 3.0 running two clustered servers. If a report ran on server 1, it succeeded. If it ran on server 2 it failed with the error.
The servers are configured identically, and BOXI is installed the same on both, except that one is the primary CMS.
Both servers were writing to a unc address that resides on a separate file server using the Directory in the form //fileserver/directory/subdirectory/subdirectory.
Both servers execute under the service account that has admin privileges on the BOXI servers. We control access to the file server directories through AD Access Groups, and the service account has rw privileges through the Access Group to the destination directories. As a result, I leave the destination username and password blank.
After investigation, I noticed that on the server 1 CrystalReportsJobServer Metrics page, Unmanaged Disk Destination Default Settings Valid was true, whereas on server 2 it was false. Since I could see no way to change it to true, I went to the Destination page on server 2 and Removed the File System entry. After saving and closing the change, I came back in and Added it again.
That changed the Unmanaged Disk Destination Default Settings Valid to true, and the reports started working.
pgeadmin (BOB member since 2007-02-14)
Thanks pgeadmin!! This was the exact situation I found myself in on BOE3.1. Your proposed solution worked like a charm! BOB saves the day again.
trwaves (BOB member since 2006-10-10)
That was a life-saver! I had seen this a few times earlier, but it was sporadic and I never fixed. Now turns out that one of my destination servers was set to True and the failing one was False.
Good find!
Brent
bdouglas 
(BOB member since 2002-08-29)
Hello pgeadmin,
can you please attach snapshot of configuration setting on all respective job, desination server and on scheduling page…
if you could provide these details, that would be great help for me …,
thanks in advance.
Vills 
(BOB member since 2007-10-24)
Vills,
I have attached a pdf that shows one of the server’s CrystalReportsJobServer Metrics page, the DestinationServer unmanaged disk configuration, and an example report Destination configuration.
Hope this helps,
Cheers,
Joseph Sunderland
PGE Corporate Reports Administrator
BOXI DiskUnmanaged Error.pdf (288.0 KB)
pgeadmin (BOB member since 2007-02-14)
I have had same problem, and found out that they way destination is written fixed the problem
when writing the destination:
\server\xxx\yy\
it is changes to
//server/xxx/yy/ when it is saved.
I was pretty sure that I had copy pasted the destination in as //server/xxx/yy/ so in my desperation I tried to type the destination in again as \server\xxx\yy\ - and the problem was fixed.
I don’t understand why - but at least I was able to run the report.
Bredholt - Denmark
bredholt 
(BOB member since 2010-04-06)
Hi all,
I have had similar problems with scheduling reports via the CMC to save to a file location on another server.
Like other people who have posted replies to the post I also experienced the source file error. CrystalEnterprise.DiskUnmanaged: Invalid error. To fix this I had to get the service account that runs the scheduled reports to have admin rights to the file location that the scheduler was attempting to write the reports to.
Hope that helps.
DEMO 
(BOB member since 2004-09-17)
Hi All… I have just joined BOB forum! This forum is really amazing and very informative…
Coming to the DiskUnmanaged issue… If I try doing what pgeadmin has suggested(to remove the File System entry under destination) will it affect the other scheduled reports?
Sorry if i sound silly… I am new to BO and im just learning!
Thanks in Advance…
Sahaana K (BOB member since 2013-10-07)
I know this is an old topic, but I was facing the same problems. It took me alot of reading, trial and error. Nothing worked. It was driving me crazy. Yesterday it came to me. For the destination path I was using the follwing:
//servername/sharename$/folder/folder/etc
I used the sharename, because our IT department didn’t want to give me the full path at first. At one moment I thought: What if they moved our department folder. So I asked again if it was possible to receive the full UNC path instead of the share$ path. I explained the situation and the person I talked to, was willing to give me the information. I changed the path to:
//servername/rootfolder/folder/folder/etc
and my problem was solved!
Hope this helps the people that are still facing this problem
raymond090576 (BOB member since 2015-07-20)