The server rebooted last night and took over an hour to reboot, doing all kinds of updates and apparently clean-up of winsxs. After all was said and done, Practiceworks doesn't. I'm new to this and am trying to fix before they get in shortly, just discovered this forum. Client PCs say they cannot connect to the server, drive mappings good, Pworks directory on server seems intact, and is not on the OS drive anyway. Help! I don't know if a service isn't working, which of the several database engines on the server it uses, etc. There was one service for MTM Mobile that won't start, but that doesn't sound like it's for desktop client use.
Okay, crisis averted. They came in this morning, couldn't get in, rebooted server, and got in. I rebooted the server multiple times myself, so no idea. I was starting to hope and pray it maybe was some kind of time-based access, but they said no. I'll talk to support when they open to learn a little something about how this works, database engine, etc.
I'm glad to hear they are back up. Just as a potential as to why you rebooting the server didn't work while their rebooting did. The Pwsvr.exe license key (gold key) will not run if someone is connected to the server via Microsoft Remote Desktop (RDP). If you were remoting in to the server using that method, that would explain why they would still get the time out errors.
Also, Windows has to fully log in for the gold key to start, and cannot be logged out, only locked.
So, to be clear, the only way to re-launch the PWSvr.exe when it crashes is to physically access the computer itself? I've tried Splashtop, TeamViewer, VNC, etc. and it just runs for a moment and stops. We're having to handle a system that's beginning to crash the gold key every few days, and it's in a physical location that's extremely difficult (and far away) to deal with.
If the PracticeWorks server can't be launched from a remote or virtual location and requires someone physically on the box, this is one of the most disappointing (and, frankly, poorly selected) "features" I've stumbled upon in a long time.
You can remote into the server with anything but the Microsoft remote desktop and it should work. Connecting using an RDP session will keep the key from running properly, and if it doesn't fully kill the key, it will keep PracticeWorks from opening correctly (on the server only).
If the key starts and then stops again, then there are other possibilities to what is causing that.
The first, and potentially most likely, is that it's not being launched from the correct location. It need to be launched from the pwsr folder inside the pworks folder, or a true shortcut to it. I've seen sometimes where it's trying to be launched from a mapped drive where the server had pworks folder mapped back to itself bc of group policy or profile startup scripts. since the Map drive path is not the true local path to the key, it won't start or stay started correctly on the server.
You can confirm the path it's expecting to launch from in the PWClient.exe application. It is located at c:\windows\syswow64\pwclient.exe once it's open click options and you'll see that path there.
Another possibility is that the Data Execution prevention is set to the second, more restrictive setting. We prefer to have it on the first setting, but if you want it to stay on the second setting then the pwsvr.exe and pworks.exe need to be added to its exclusion list so they aren't stopped from being launched. This however typically keeps it from launching at all.
another option could be that the key is running on another computer somewhere in the office. Either an old server is still on the network and has it's key still able to run. Or someone ran the disk on another machine and it installed the key there and it's trying to run at the same time.
The last possibility that comes to mind is that the gold key application, or another file in the pwsvr folder, corrupted. usually at that point we can rename the pwsvr key, run the disk again to rebuild it, then drop in the pwlf.dat license file again.
as far as the key crashing every few days, but it does stay on at least for a period of time, mmm it could be either one of the last two options I mentioned. But it could also be something else in the system that is killing the process.