We have a application deployed in a Citrix environment. Many workstations can print to the Citrix print server fine via our application, but 2 cannot (this is limited to our application ie MS Word document prints fine). Of the many workstations, 2 with issues are on the same host as other workstations without issues. There are no printing issues with our application on other workstations. The application is published from the same host. Not having a Citrix background not sure how to go about troubleshooting this.
Check that Citrix host (on which users have issues) have the same policies applied comparing to others. In Citrix XenApp 6.0 and higher run AppCenter console and inspect policies and WorkerGroups they applied on.
Secondly, check Citrix host Windows Event Log for printing errors or printer creation errors.
And lastly check print server for received print jobs and their status.
Related
My Delphi 10.4 application uses a HTTPRIO-component to communicates with SOAP REST Server over HTTPS.
It is installed on more then 100 PC's, and it works fine almost everywhere.
However, I now have 2 clients that get the following error:
"Error sending data: (12030). De verbinding met de server is niet normaal beëindigd"
(--> The connection to the server did not end normally )
The user has a Windows 7 Home Premium machine (I have Windows 10 Pro).
Firewall was disabled.
If I copy the complete application-dirctory with all the dll's to my machine everything works fine.
Where should I start looking for a solution?
Which properties of the HTTPRIO-component could have an effect on this behaviour? Or which dll's?
I checked the article Peter Wolf suggested but without succes. (The register-settings should be OK). All the registers are present with the right values, but the windows update could not be installed. Also downloading the stand-alone update KB3140245 fails. It juist says "failed".
any hints are welcome!
kind regards,
Dirk Janssens
I'm working with the following:
Docker for Windows v20.10.11
Docker running in Windows container mode
mcr.microsoft.com/windows:1903 base image
Proprietary application installed on top of this base image
Each year we create a Docker image with the latest version of our company's software. However this year's version behaves differently. Host machine installation runs fine. Containerized installation fails to run in certain situations. I can start the application as a simple EXE, for example using the Docker run command. The app will start and show up in "tasklist". However I can't start the app via the COM API, which is a critical requirement. The problem appears to be COM related. Normally we can create COM objects for our software just like for any other application. For example, IE returns a COM object just fine:
Creating these objects for our application works outside containers. However inside the container, our latest installation gives this error:
Access permissions appear to be ok. I tried a couple tests to prove this. First I can install other software like MS Word into a container and create COM objects for that:
Second I tried retrieving + modifying the application's DACL in PowerShell.
Changing access masks or trustees can cause an Access Denied error:
This also appears to confirm the access permissions were Ok by default.
Next I made sure COM is aware of the application. This appears to be fine. I get the same result on host machine and container when running this PS script:
gci HKLM:\Software\Classes -ea 0| ? {$.PSChildName -match '^\w+.\w+$' -and
(gp "$($.PSPath)\CLSID" -ea 0)} | ft PSChildName
The application shows up just like any other. The details show up fine when querying by AppID. LocalServer32 points to the correct EXE:
Some other things I tried:
Querying registry keys. There are 7 keys created when installing our software. These appear identical on host machine install and container install.
Even though permissions appear fine, I still tried logging into the container as alternate users. For example "nt authority\system" is another virtual admin user. I also changed the password of the "builtin\administrator" user to enable logging in with that one. Lastly tried creating new users entirely and adding them to the Administrators user group. All these attempts had the same errors as "builtin\containeradministrator" (default user).
A minor check was ensuring CMD.exe / Powershell is running as x64:
Re-registering the DLLs associated with the installation using regsvr32.
Starting from different base images. https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images. The full Win Server base image behaves exactly the same way regarding errors. The smaller Win Server Core base image is even more problematic, as I can't even start the app's EXE manually using that base. Lastly I tried other tags of the full Windows base image such as 20H2 and 2004. Same result from those. Multiarch or x64 makes no difference.
Included the "Ogawa hack" which was historically needed to make MS Office apps function correctly with COM: https://stackoverflow.com/a/1680214/7991646. It could be necessary for other COM apps too, but didn't help with my specific installation.
Is there anything else I can do to diagnose or solve this COM issue?
There are several things to consider:
The Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
The When CoCreateInstance returns 0x80080005 (CO_E_SERVER_EXEC_FAILURE) page describes possible reasons.
If many COM+ applications run under different user accounts that are specified in the This User property, the computer cannot allocate memory to create a new desktop heap for the new user. Therefore, the process cannot start. See Error when you start many COM+ applications: Error code 80080005 -- server execution failed for more information.
Finally, you may find a similar thread here helpful, see Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
I am experiencing a strange issue when publishing an ASP MVC application to Windows Server 2012.
The app is fairly simple, and on most of the pages visited it will query an Access database which is hosted on the server.
I noticed that the queries are quite slow (often taking between 7-10 seconds to complete), as shown when running the app with MiniProfiler.
As a simple test, I decided to host the app on my Windows 10 laptop to see if there was a difference, and it is much faster (Most queries are under 200ms).
This is what I tried so far:
Match advanced Application Pool settings
Match Firewall settings
Enabled link local multicast name resolution (LLMNR)
Confirmed that ODBC tracing is disabled (32 and 64)
Moved the Access Backoffice.mdb file to the server's C drive (same as on the laptop)
Made sure web.config match (apart from connectionString Data Source)
Added C:\inetpub\wwwroot\website and C:\Test\Database to antivirus scan exclusions
Increased the MaxBufferSize key value from 0 in Access Connectivity Engine in the registry
Does anyone know of a way that I can try debugging this issue, or any possible solutions?
notes
Both my laptop and the server are on the same network while testing this, and I am accessing the app from an ipad.
I am also experiencing the same slowness when using the application from a browser on the server itself (url = 10.0.0.1 or localhost)
When I execute the exact same query code from a console app on the server, it runs a lot faster (on par with the laptop). I am only experiencing this issue via the asp app.
Laptop Details:
Processor : Intel Core i7-6700HQ CPU # 2.60GHz
RAM : 16.0 GB
OS : Windows 10 x64
Server Details
Processor : Intel Xeon CPU E5-2603 v4 # 1.70GHz (2 processors)
RAM : 32.0 GB
OS : Windows Server 2012 x64
Connection String
I have tried the following:
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=W:\My Backoffice.mdb
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Test\My Backoffice.mdb
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=\\ServerName\W\My Backoffice.mdb
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=\\ServerName\C\Test\My Backoffice.mdb
With both 16.0 and 12.0 as the ACE.OLEDB version, where W is a Local server drive which is used as a network share acrcoss the domain. All of these gave the same result.
We have used Google Cloud Print Service for a few years now, very successfully. Periodically we have issues with print jobs failing, where restarting the Cloud Print Service and the Print Spooler will fix it. That is not the case today.
Today, I am able to print directly to the printer, both from my computer and from the server where we host Google Cloud Print Service. When I attempt to print from Google Cloud Print, I see the print job appear in the queue on the server, and then disappear, and in the Cloud Print queue it simply says "error" with no details on what is happening.
I restarted the print service with logging enabled, attempted to print again, and checked the debug log, with no details present. I'm stumped.
EDIT: After finding the correct debug log, I see this:
CP_CONNECTOR: Job failed (spool failed)
Has anyone dealt with this before, or know of a solution?
Things I have already tried:
Re-connecting Cloud Print Service to our Google account
Re sharing all printers
Reinstalling Cloud Print Service
Restarting the server
Reinstalling printers
After doing many many things, and finally getting Google support on the line, we determined it was a glitch in the Cloud Print Service. The work around, which I was unaware of, and the reason I'm posting this answer, was to use the Chrome Connector.
You can get to that by visiting chrome://devices and then sharing the printers through that form, which looks identical to the one that you get with the Cloud Print Service. I recommend clearing your printer list from Cloud Print first, so you don't get confused.
Once you've shared them, you can then share the printer through Cloud Print just as you would have before.
The only caveat, and the reason this is a work around and not a fix, is that you have to maintain an open Chrome session, meaning you have to keep chrome open for the printers to work. That's fine for us, as there is always a chrome tab open on the server anyway, but it may not work for you long-term.
I have installed the Beta version of chrome, and it seems to resolve the issue. I had this issue on 3 of my 11 servers. All where running stable versions. It was odd that only 3 where not allowing google to print. Once I installed the 64bit beta version, I was able to print. As long as the server was running the Version 53, people could print. It did not matter if someone had a version 52 on there computer. Hope this helps.
I have an application named “LeafTest” which has Server Edition and Client Edition. The server Service is “Mss.exe” which is running under account “stepup” account which I checked from “services.msc” and system configuration is 2003 server 32bit standard edition with SP2. But yesterday means November 20 it suddenly stopped , I don’t know what is the reason behind it.
When I checked my application logs I can see these errors just before it reported service stopped
The entries in event log are
Following error also i can see somewhere
Event ID ( 8500 ) in Source ( LeafTest)
cannot be found. The local computer may not have the necessary registry
information or message DLL files to display messages from a remote computer.
When I go0gled somewhere its mentioning my application may not be installed properly or registered or I need to work with registry. Can any body tell me what will be the reason behind the service stpped by reading logs which i have posted
A service may halt if there is an unhandled exception. Check that you are handling all exceptions. Also, if the service uses any COM objects I have, in the past, had exceptions that could not be caught in my .NET 2.0 applications.