Remote Printing error from Axapta 2009 via RDP
Hello,
I am having an issue trying to print checks to a remote printer from Axapta 2009, via an RDP session. To be fair, it's not a 'typical' type of connection--here is how it is laid out:
We host the AX system on our domain, ABC.lcl, which is a server 2008 domain. Our sister company is in Canada (we are in the US), and exists on a totally separate SBS2003 domain, however they share our accounting system by connecting to the AX platform via a Server 2008 Remote Desktop Server.
The client can establish her connection fine, and her printers are redirected properly (windows test pages work fine, as well as pages created from AX using the SSRS server.
She can also print checks using her Samsung CLX6240 (printer is attached to her network, the SBS server is also the print server)... however, this printer is not MICR-capable, so I had to install a dedicated printer. We chose an HP P1606 due to its size and cost, but I get the following error when attempting to print checks to it:
endPage: rc:SP_ERROR
abortDoc: rc:SP_ERROR lastError:3003(0xbbb) A StartDocPrinter call was not issued
I have tried setting up the 1606 both as a network printer (drivers installed on the SBS 2003 server), and as a USB connected printer directly to the client's workstation... the error is the same in either configuration.
Initial Google searches kind of pointed to this being potentially a network security issue, which I could totally see being tricky because of the separate, untrusted domains being involved... but the ability of the Samsung to print the checks negates that argument. To be safe I granted Everyone Allow permissions for Print, Manage Printers, and Manage Documents on the printer.
This makes me believe that it may be a driver issue, but I don't know for sure that is the case.
I am using the 32-bit PCL6 version of the driver.
Any ideas how I can troubleshoot this error?
Thanks,
Scott
I am having an issue trying to print checks to a remote printer from Axapta 2009, via an RDP session. To be fair, it's not a 'typical' type of connection--here is how it is laid out:
We host the AX system on our domain, ABC.lcl, which is a server 2008 domain. Our sister company is in Canada (we are in the US), and exists on a totally separate SBS2003 domain, however they share our accounting system by connecting to the AX platform via a Server 2008 Remote Desktop Server.
The client can establish her connection fine, and her printers are redirected properly (windows test pages work fine, as well as pages created from AX using the SSRS server.
She can also print checks using her Samsung CLX6240 (printer is attached to her network, the SBS server is also the print server)... however, this printer is not MICR-capable, so I had to install a dedicated printer. We chose an HP P1606 due to its size and cost, but I get the following error when attempting to print checks to it:
endPage: rc:SP_ERROR
abortDoc: rc:SP_ERROR lastError:3003(0xbbb) A StartDocPrinter call was not issued
I have tried setting up the 1606 both as a network printer (drivers installed on the SBS 2003 server), and as a USB connected printer directly to the client's workstation... the error is the same in either configuration.
Initial Google searches kind of pointed to this being potentially a network security issue, which I could totally see being tricky because of the separate, untrusted domains being involved... but the ability of the Samsung to print the checks negates that argument. To be safe I granted Everyone Allow permissions for Print, Manage Printers, and Manage Documents on the printer.
This makes me believe that it may be a driver issue, but I don't know for sure that is the case.
I am using the 32-bit PCL6 version of the driver.
Any ideas how I can troubleshoot this error?
Thanks,
Scott
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
well mostly if that is the case i solve this by making a vpn connection and installing the printer as a local printer on the server (via tcp/ip printing or lpd) that way the name is fixed.
ASKER
I know the VPN is an option, but I am trying to work through the rdp solution first, before purchasing the VPN licenses
ASKER
I'm accepting this comment and closing the question. The problem wasn't resolved, but I am no longer at the company in question, and it didn't seem right to deny PlusIT the points after their efforts!
ASKER
I will hunt around to see if I can work out how to stop the renaming. If you have any ideas, please let me know.