We’re installed now, and printing to a newly acquired label printer, but I can’t see a legit way of keeping the QuickShip Printing Client running while installed on a server. They said it should be on a PC like the Shipping station, but we ship from 5 time zones and PC’s go to sleep. I know I can keep one awake, but a server sounds like the right choice - yet we don’t have a user logged into our servers (they are VMs).
So, in these cases the client becomes useless… Anyone install the EXE as a “service” in the OS yet?
Yeah, I think that’s part of my problem. I went ‘cloud’ with it so there is a local ‘client’ like the Kinetic Edge Agent. I might have to consider bringing it back in house to remedy this.
We use a server for this and it is running all the time, unless you reboot it. I asked about running it as a service and QS said they ran into issues doing that. Unfortunately, we have to go in and kick it off after a reboot.
Quick Ship printing is based on mapped printers tied to the workstation the user is logged into in Quick Ship/Epicor. Whatever server you install the QS client on needs to have the printers mapped to the user profile running the executable. The client is just looking at an Azure blob for the files generated out of QS cloud based on the tenant ID and downloads them to the JobDirectory. Once the xsd (data file) get processed through the report, it uses the .mon (where to print it) file to send it off to the printer. Once complete it goes into the Archive, or unprocessed if it is a failure.
Edit: hopefully all 5 time zones can communicate with the printers. Otherwise, I’m not sure how QS would determine location other than the WorkStation Key in the client settings?
@ajohnson Thanks, and I think I’m good all the way around with mapped printers and the like. We had a very technical conversation with the implementation team to make sure it would all work otherwise. This topic is just one of the shortcomings in QuickShip that we are working around. The others include Crystal reports, LTL Rate Shopping, and multiple weights and dims per shipment without using Mater/Phantom packs.
I just want to see if anyone solved the manual-ness of the client.exe. What I found was that if a user is not logged into a session on the server, the client stops as well as when it crashed/reboots/etc. This means that you have to maintain a login, and manually monitor/restart the process when anything adverse happens. That is pretty silly considering the client could easily be written to the .Net specification for headless/standalone operation as a background OS service and still allow for an interactive application to control features like configuration and the like.
However, I’ve found a program in the link above called AlwaysUp and it seems to be working quite well. For $50 for a single server, I think I’ll go that route. It’ll handle restarts, notifications, crashes, etc.
We only have one instance of the client installed to process printing. In fact QS recommended only one since multiple could interfere with each other. We do not have any users log into the server. Everything is processed by ERP or in those annoying cases, logging into the web interface of QS.
I’ll have to explore the other apps to keep the service running. I was also disappointed in changing the executable, the didn’t run it as a .net service. It used to be worse if that helps
On the server, if no one is logged in, then the client isn’t running. You can log in, start the client, and then disconnect - as long as you don’t log out - and the client will stay running. We don’t allow for logons to persist without activity, so there is ‘no user logged in’ so the client can run.
After my first day with AlwaysUP, I’m very pleased. It sends me an email each night showing the previous day’s activity and last night my server rebooted at 5:30 for a Microsoft patch it seems. Got this pretty email this morning saying everything is OK and it’s running…
Great input from everyone!
We are not even there yet to complain, but trying to install the Cloud Print Service Monitor on Server 2016 and it won’t install because the Administrator account is not granted the “Login as a Service” right, and we cannot get that right assigned via GP.
Anyone have a recommendation to install it?
I installed in on a different server than our Print Server which is a 2012 OS and it installs fine, but not on Server 2016.
Any recommendations appreciated from those who have struggled… lol
A gripe we already see also is with HazMat shipments. None of the “Standard” HazMat codes are entered out of the box. Seems silly that they don’t pre-populate those which are readily available on the web anyway and it is a Cloud offering.
UPDATE
Support has reported this issue already and recommends the local install to client.
-----snip----
We have already reported this issue PRB0274425 to our development team and they are working on it, mean while please use the Quick Ship Windows client instead of the service for printing labels and documents.
