Using v3.1 SP7…
I’m getting the above error when sending the output from a publication to a file location. The correct account and password details have been input, but it still fails.
The strange thing is, sending the output from a scheduled document to the same location works. 
Any ideas anyone?
anorak 
(BOB member since 2002-09-13)
Hmmm, seems weird, as far as I know (not dealt with this stuff for a while) is that the destination job server should be used in both cases, so that should be picking up the user account the SIA is running under.
Might be worth a check of all the BOXI processes on the server to see what user context they are running under? It`s not a horizontally scaled environment is it?, and processes could be running on a different machine and could be running processes under different user contexts.
All worth a check?
Owt in the event logs?
ABILtd (BOB member since 2006-02-08)
Well, after much investigation, I read a posting that suggested adding the Domain Name to the User Name credentials, and this worked!
So, to check that this was the cause of the problem, I then removed the Domain Name, but it still worked.
I then removed the password (because the posting that I read had also suggested this), and it sill worked.
I then tried another user’s account both with and without the Domain Name but no password, and this did not work. However, it did manage to lock out her Windows login, as we have a ‘3 tries and your out’ Windows login policy. She’s not a happy bunny!
Can anyone explain what’s going on with the Domain Name business, and why you should need it for Publications but not for scheduling?
Good old Business Objects standardisation!
anorak (BOB member since 2002-09-13)
It doesn`t make sense. I think they wrote that code on a Friday…
ABILtd 
(BOB member since 2006-02-08)
Unfortunately, my success was short-lived 
I cannot get Publications to send output to a Red Hat Linux box, even if I include the Domain name in the logon.
Schedules work though! Absolutely bizarre
anorak (BOB member since 2002-09-13)
Does this user account have write access to the Linux box?
Did you restart the SIA after changing the log in details?
Is rexec enabled?
https://scn.sap.com/thread/3294808
Mak 1 (BOB member since 2005-01-06)
Mark,
Thanks for the suggestions.
I am not an Administrator and do not have access to CMC, but wouldn’t all of what you suggest affect both Schedules and Publications. I can schedule output successfully, but just not through Publications.
I’ll ask the question about ‘rexec’
anorak (BOB member since 2002-09-13)
Hi Anorak,
rexec is required to be enabled if you enter a users account details?
When scheduling you are using the domain level service account, correct?
Worth reading through that post and checking in any case.
Cheers,
Mark.
Mak 1 (BOB member since 2005-01-06)
Mark,
Apologies if these are dumb questions, but I’m not an Administrator.
Is ‘rexec’ a Linux specific thing? Our BI servers run on Windows Server 2003, but I am wanting to send the Publication output to a Red Hat / Linux box.
I am using a specific account / password to login, which works with Schedules, but fails with Publications.
Is ‘rexec’ relevant in this case.
Thanks…
anorak (BOB member since 2002-09-13)
rexec is a Linux component, which requires installation.
Ah, I thought that the scheduling was using the BO service account and you were using a named account soley for the publication.
If you are using the same type of named account, for both, then rexec should be installed on Linux.
Unsure why they do not work in the same way :?
Mak 1 (BOB member since 2005-01-06)
Just to clarify…
So when you say ‘rexec should be installed on Linux’, you mean on the destination server, nothing to do with the BO servers?
anorak (BOB member since 2002-09-13)
Yup, confirmed.
Mak 1 (BOB member since 2005-01-06)
For information, this is the reply that I got:
“rexec is an insecure method of allowing commands to be run on a remote system. rexec is not required to mount a Samba (smb/cifs) filesystem.”
It doesn’t really mean much to me, but the bottom line is that it still doesn’t work! 
anorak (BOB member since 2002-09-13)
I don’t think it will work otherwise, if you go through the link I posted above. I must admit I haven’t gone through all the KB links in there.
I also don’t understand how the schedules are still getting there :?
Mak 1 (BOB member since 2005-01-06)
Mark,
I’ve now managed to get my hands on these KB articles (I don’t have a SAP account). However, they all to relate to issues where the BO servers are running under Unix. Ours aren’t, they are on Windows Server 2003; it’s just the destination server for the Publication output that is running Linux.
All very confusing.
anorak (BOB member since 2002-09-13)
Yes confusing.
Can the user manually copy a file into the Linux directory.
Is the publication of a large size?
Mak 1 (BOB member since 2005-01-06)
Manually copying the file works. Very small test file being used.
anorak (BOB member since 2002-09-13)
Mark,
Just a final update regarding this problem…
Unfortunately, I’m never going to be able to test this as my contract finishes at the end of the month, and the required BO / server admin resource is not available at present.
However, SAP have suggested that the BO SIA account also needs read / write access to the destination Linux server even though we are providing a specific account / password when sending the output of the Publication. This does not make sense to me, but a wise ex-SAP consultant that I know has suggested the following reasons for it:
“It may also be that the service account needs access to the share first to do some checks and then the account you use actually does the saving who knows!!! Different teams write different modules so its possible (probable) that scheduling and publications use different workflows and code.”
This would explain why scheduling works but Publications do not.
anorak (BOB member since 2002-09-13)
Sounds totally feasible.
I thought a domain level Windows account would cover it.
Mak 1 (BOB member since 2005-01-06)