Remote Application Installation
Comments
-
JDMurray Admin Posts: 13,090 AdminGPT-4 sez:
If the Quotewerks support team has pointed toward potential network-related issues and other common problems have been ruled out, let's try to diagnose and tackle the problem step by step.Network Shares and Permissions:Ensure that the shared folder containing the Quotewerks database has the appropriate permissions for the user accessing it.Check if there are any latency issues when accessing the shared database. Prolonged latency can make applications hang or become unresponsive.Isolation Test:As a test, copy the Quotewerks installation file and database locally to the Windows Server 2019 Terminal Server and attempt the install and run again. This will help determine if the network or the shared location is truly the issue.Firewall/Security Software:Ensure that any firewall or security software on the Windows Server 2019 Terminal Server or on the network isn't blocking or slowing down Quotewerks. Consider temporarily disabling them to see if it resolves the issue. Remember to turn them back on afterward!Event Viewer:Look in the Windows Event Viewer on the Terminal Server under both the "Application" and "System" logs around the time of the Quotewerks crash. This might provide more details on what's causing the application to become non-responsive.Database Connection:Ensure that the connection to the database (whether it's SQL or another type) is stable. Sometimes connection timeouts or incorrect connection strings/configurations can cause applications to hang.Application Compatibility:Try running Quotewerks in compatibility mode. Right-click the application shortcut or executable > Properties > Compatibility Tab > Check "Run this program in compatibility mode for:" and select a different Windows version.Network Diagnostics:Use tools like "ping" or "tracert" from the Terminal Server to the server hosting the Quotewerks database. Look for high latencies or dropped packets.If you have the capability, monitor the network traffic between the Terminal Server and the server hosting the database when you start Quotewerks to see if there's any unusual activity or disconnections.Profile-Related Issues:Sometimes, user profile issues can cause applications to behave unexpectedly. As a test, create a new user profile on the Terminal Server and try installing and running Quotewerks under that profile.Software Dependencies:Ensure that all software dependencies required by Quotewerks (like specific .NET Framework versions or other libraries) are correctly installed and updated on the Terminal Server.Reinstall:Uninstall Quotewerks, restart the server, and then attempt a fresh install.Remember, the key is to isolate the variables. By narrowing down the potential causes, you'll be in a better position to identify and resolve the issue.
-
ic3hatt Member Posts: 16 ■■■□□□□□□□I really appreciate your help. So i failed to mention that I did try most of these things but maybe you can help fill me in where I went wrong.
First and foremost, I checked the permissions on all users and made sure everyone has full access to the entire QW folder which is where the database and application files are held. I ran ping and im getting <1ms from the term server to the database. I also ran a tracert, 1 hop, same thing. I completely disabled the firewall. I tried running QW in compatibility mode. I've created a new profile and tried running the application. I confirmed I already had all versions of NET framework installed already and confirmed on the website what was required as far as software components. I've completely uninstalled the application and reinstalled it after removing all remnants of the application. I also did all of these things one at a time to make sure Im isolating as you suggested. I have not yet checked the logs but I assume that's next. -
stevesiggs Member Posts: 5 ■□□□□□□□□□In the original post, you stated that "using an installation file that is on another server that I've shared the database for" and so I am assuming that you ran the "nsetup.exe" to install QW to the 2019 server.
When you ran nsetup, did you put the 2019 server into install mode? (Command prompt "change user /install", then "change user /execute" after the installer has run.)
As I understand it, it's only once you get past the login screen that QW locks up. Have you tried logging in as different QW Users? (Sometimes it can be a corrupt QW User Profile that causes odd errors.)
When QW appears to hang, try using Alt-tab to see if there's a Window open waiting for input that's hidden somehow.
Do you have a Contact Manager integrated with QW? Try turning that integration off temporarily... does that solve the issue?
Have you tried installing QW stand-alone on the 2019 server? I.e. download the full install from the QW website and just install that locally to C:\Applications\QuoteWerks (i.e. anywhere but Program Files) and see if that works.
Let me know how you get on! -
ic3hatt Member Posts: 16 ■■■□□□□□□□stevesiggs said:In the original post, you stated that "using an installation file that is on another server that I've shared the database for" and so I am assuming that you ran the "nsetup.exe" to install QW to the 2019 server.
When you ran nsetup, did you put the 2019 server into install mode? (Command prompt "change user /install", then "change user /execute" after the installer has run.)
As I understand it, it's only once you get past the login screen that QW locks up. Have you tried logging in as different QW Users? (Sometimes it can be a corrupt QW User Profile that causes odd errors.)
When QW appears to hang, try using Alt-tab to see if there's a Window open waiting for input that's hidden somehow.
Do you have a Contact Manager integrated with QW? Try turning that integration off temporarily... does that solve the issue?
Have you tried installing QW stand-alone on the 2019 server? I.e. download the full install from the QW website and just install that locally to C:\Applications\QuoteWerks (i.e. anywhere but Program Files) and see if that works.
Let me know how you get on!
when i initially did the install yes I did use the nsetup.exe program on the terminal server. Yes I also made sure to run the install in install mode and immediately after the installation finished switched to execution mode. I have tried using a different QW login. After your post I also tried alt+tabbing but no luck there either. When you refer to the contact manager integration... I just went to utilities and selected none and then hit "ok". Im assuming that disabled any contact manager integration. And yes I already have tried the local install of QW and that worked. So i know it is something related to my network.
These were all great suggestions, but still no luck. Any other ideas? -
stevesiggs Member Posts: 5 ■□□□□□□□□□>> When you refer to the contact manager integration... I just went to utilities and selected none and then hit "ok". Im assuming that disabled any contact manager integration. <<
Were you able to do that on the 2019 server? Or went to a.n.other workstation where QuoteWerks is working ok?
What was the Contact Manager set to before you selected "(None)"? Selecting "QuoteWerks" might also be worth a try. Be sure to click 'Ok', then close and reopen QW after doing this.
Also try opening the Medic Utility and going through the options on the Utilities menu to see if any of those throw up anything.
Finally (at least for now!) are there any non-native QuoteWerks databases set up in the Products menu -> Setup Product Data Sources screen? (A screenshot of these might be useful if you're not sure which are / are not native QuoteWerks databases. -
ic3hatt Member Posts: 16 ■■■□□□□□□□Were you able to do that on the 2019 server? Or went to a.n.other workstation where QuoteWerks is working ok?
After leaving QW alone for around 5-10 minutes the application starts to respond. That has been constant throughout the process so I made that change on the 2019 term server. Before I selected "none" the contacts manager was set to Zoho.
I will look at the quotewerks databases and see if i find anything.
The only medic utility i found was on the database server in the QW folder.. Im worried that if I run it, it might cause issues for anyone currently using QW. (Everyone currently uses the database server as a terminal server, the reason i am going through this trouble is so that we can have 1 server as an app server and one server for the database. Currently everyone logged into the database server as well as locally on their home computers has no issues.Will running this medic utility require me to have everyone offline or could it cause issues?
Here is a picture of the product data source screen
https://imgur.com/a/KgnthcD -
stevesiggs Member Posts: 5 ■□□□□□□□□□>> Everyone currently uses the database server as a terminal server, the reason i am going through this trouble is so that we can have 1 server as an app server and one server for the database. <<
Is the DB server acting as a Remote Desktop server too?
Is the App server in the same domain as the DB server?
I think you may have covered this previously, but does the share on the DB server where QW is allow Users "Full Control" over all files and sub-folders?
Perhaps also try letting "Everyone" have "Full Control" temporarily to eliminate that.
Perhaps try turning the firewall off on both DB and App server off temporarily to eliminate that.
>> Will running this medic utility require me to have everyone offline or could it cause issues? <<
For running some operations (like the Data Manager or Database Maintenance) it requires all Users to be out, but the Medic will prompt you and not allow you to continue and so you should be ok. Data Manager isn't relevant here; Database Maintenance might be, but we can come back to this later, if required.
>> Here is a picture of the product data source screen <<
Nothing untoward there, but it does seem to suggest that you are using QW with the MS Access backend. Is that correct? (A screenshot of the QW Help menu -> About tab will help if you're not sure.) -
ic3hatt Member Posts: 16 ■■■□□□□□□□Is the DB server acting as a Remote Desktop server too?
If you mean, do we have terminal services enabled and have people rdp into the server to access their profile, yes it does.
Is the App server in the same domain as the DB server?Yes, they are in the same domain and I have confirmed this is not an issue. We are able to login normally and access all local files on their respective profiles accurately.
I think you may have covered this previously, but does the share on the DB server where QW is allow Users "Full Control" over all files and sub-folders?Yes, the QW folder on the DB server has full control permissions given to "Everyone" over all files and subfolders.
Perhaps try turning the firewall off on both DB and App server off temporarily to eliminate that.I have tried that on the new app server but have not tried turning it off on the DB server. I will try that and let you know.
Thank you for the confirmation on that medic utility.
Yes, that is correct there is a Microsoft Access backend used here, I've confirmed in the About>System tab.
-
ic3hatt Member Posts: 16 ■■■□□□□□□□ic3hatt said:Is the DB server acting as a Remote Desktop server too?
If you mean, do we have terminal services enabled and have people rdp into the server to access their profile, yes it does.
Is the App server in the same domain as the DB server?Yes, they are in the same domain and I have confirmed this is not an issue. We are able to login normally and access all local files on their respective profiles accurately.
I think you may have covered this previously, but does the share on the DB server where QW is allow Users "Full Control" over all files and sub-folders?Yes, the QW folder on the DB server has full control permissions given to "Everyone" over all files and subfolders.
Perhaps try turning the firewall off on both DB and App server off temporarily to eliminate that.I have tried that on the new app server but have not tried turning it off on the DB server. I will try that and let you know.
Thank you for the confirmation on that medic utility.
Yes, that is correct there is a Microsoft Access backend used here, I've confirmed in the About>System tab.
-
stevesiggs Member Posts: 5 ■□□□□□□□□□So I'll await feedback on the Medic Utility.
You mentioned earlier that QW omes out of it's "not responding" state after 5-10 minutes. Once it is working, does it work 'ok'? Can you search and open documents ok? Is it at all sluggish compared to using it on the DB server? Can you Preview documents ok? Print and email them? Can you retrieve contact infrmation from Zoho ok? Save documents and update details in Zoho ok? -
ic3hatt Member Posts: 16 ■■■□□□□□□□stevesiggs said:So I'll await feedback on the Medic Utility.
You mentioned earlier that QW omes out of it's "not responding" state after 5-10 minutes. Once it is working, does it work 'ok'? Can you search and open documents ok? Is it at all sluggish compared to using it on the DB server? Can you Preview documents ok? Print and email them? Can you retrieve contact infrmation from Zoho ok? Save documents and update details in Zoho ok? -
stevesiggs Member Posts: 5 ■□□□□□□□□□I'm not sure that QW writes to the Windows Event Log... not unless there's a fatal App crash. There are some text ".log" files in the QW application file directory, but these tend to just log errors or log stuff when particular processes are being run (like an update or import). I'm a software engineer, so not overly familiar with these types of things, but hardware techies talk about "packet sniffers" in trying to analyse what may (or may not) be going on if you want to analyse that type of thing.
I can't really comment on the "not responding" state, but my feeling is that QW is trying to connect to 'something' - usually it's a printer, Product data source, contact manager, but we seem to have eliminated all of those as possible causes. Clutching at straws a bit here, but when you are able to get into the Medic then that might offer something useful. Also when all Users are out of QW run the Medic Utility "Maintenance" routine to compact and repair the databases - that might help too. The "Maintenance" takes a backup of the ".mdb" files before it runs, so minimal danger of doing something that can't be undone. For 'belt and braces' certainty, taking a complete copy of the QW application directory before you start is a good idea - you'd then just have to reinstate that back if things don't go according to plan.
Final thoughts (for today at least!)
* What version and build of QW are you running?
* And how big are the MS Access ".mdb" files in the QW directory? (A screenshot might be useful so I can see if there are anomalies to what I'd expect.)
* I've been assuming that the DB and App server are hard-wired into the same network, but let me know if they are connected wirelessly, over VPN or other way as this could be a factor.