Options

Remote Application Installation

ic3hattic3hatt Member Posts: 16 ■■■□□□□□□□
edited September 2023 in Troubleshooting
I am having an issue on my Windows Server 2019 Terminal Server. Im trying to install quotewerks. Im using an installation file that is on another server that I've shared the database for. It appears to install correctly. However when I start the application, Quotewerks immediately goes non-responsive. I spoke to QW support team and they say it might be related to our network. We've already looked into non-network issues such as layout issues and printer configuration issues which are a common cause of this crash. 

Anyone have any idea where I could go from here? I've made sure to fully uninstall and clear any files by following a guide on which registry files to delete and appdata files to remove (backed up reg first). Then i made sure to set the term serv to install mode. ran install as admin. switched back to execute mode, ran app as admin. It does in fact load the database so i know it's communicating with the server because all of the usernames to login appear. But once I log in. BOOM. non-responsive. Please any help would be greatly appreciated. Been working on this for weeks.

Comments

  • Options
    JDMurrayJDMurray Admin Posts: 13,034 Admin
    GPT-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.


  • Options
    ic3hattic3hatt 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.
  • Options
    stevesiggsstevesiggs 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!
  • Options
    ic3hattic3hatt Member Posts: 16 ■■■□□□□□□□
    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!
    Thank you for your response,

    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?
  • Options
    stevesiggsstevesiggs 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.
  • Options
    ic3hattic3hatt Member Posts: 16 ■■■□□□□□□□
    edited September 2023
    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



  • Options
    stevesiggsstevesiggs 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.)
  • Options
    ic3hattic3hatt 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.

  • Options
    ic3hattic3hatt 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.

    I have confirmed that this whole time I've been trying it with the firewall disabled on both servers.
  • Options
    stevesiggsstevesiggs 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?
  • Options
    ic3hattic3hatt Member Posts: 16 ■■■□□□□□□□
    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?
    I have to wait on the medic utility due to it being in use right now but yes everything works fine after the 5-10 minute hang... Is there a way I can find all event instances related to quotewerks in event viewer? I want to be able to see all events related to this occurance. I've also looked at task manager when this occurs and noticed that the application also immediately shows up as not responsive in task manager as well, which to me caught me off guard because I thought normally if the issue was related to a network the application would still show up as responding in task manager...
  • Options
    stevesiggsstevesiggs 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.
Sign In or Register to comment.