After a user getting an error that their SN was already in use, and then with Enterprise continually Not Responding after a restart, I thought I’d do a reinstall hoping for not a lot of work to get it back up. I deleted all of the ProVUE preferences from the Library. Then after a reinstall from a fresh download, I am now getting an error
Serial Number: 71xxx.9rj
Not licensed for this version
This serial number is not licensed for use with Panorama Enterprise Server version 6.0.0
This is immediately after doing the re-install and exiting the installer to then have been moved to the Activation page. I’ve not yet entered the SN. The error is complaining about what it already knows. (This SN was already in use prior to the problems and the reinstall. (The x’s are different numbers.))
Attempting to launch the server after the fresh install (and not resolving the error of the SN), causes Panorama Server to be a Non Responding application in the Activity Monitor.
Gawd how I hate copy protection. I have an doctor’s office of 14 people unable to work because the copy protection is broken with all of them waiting for me to fix it.
You provided enough of a clue that I was able to figure out the serial number. It is in fact a valid Panorama 6.0 Server serial number.
I assume that the message you listed is from the Registration window. This message is appearing because that serial number does not have a Panorama 6 client license, only the server license. The Registration window only knows about the status of the client license, not the server license. So it is correctly reporting that you do not have a valid client license. However, if you run Panorama Server.app you should find that it works fine.
I think you are thinking that this would get rid of the Panorama 6 serial number. It does not — Panorama 6 does not store the serial number in the Library folder. The serial number code pre-dates the OS X transition, the “classic” version of Panorama still includes code designed for MacOS 9 (and earlier), and of course there was no library folder in MacOS 9. Many of you appreciated this when you were able to dual boot between MacOS 9 and OS X and keep your Panorama registration working.
I’ve removed several potentially corrupted db’s from the Enterprise/Public Databases folder and the Server window now temporarily presents itself but then after a moment or two, it goes away as the Server app has crashed. Interesting that removing some databases will allow Server to at least present its box but server continues to crash. Not too sure of the best way to move forward. Before removing some db’s, the server window did not present itself.
It sounds like you might want to remove all databases on the server and see if that works, then you could gradually introduce them one by one. In any case, it would appear that the problem has nothing to do with the serial number.
I have seen situations where the recovery journal causes Panorama Server to crash, so it is worth trying removing the .jnl files but leaving the databases.
This error will be returned by Apache if Panorama Server is not running. The Apache plugin panorama.cgi uses Apple Events to communicate from Apache to Panorama, and this error will happen if Panorama Server is not running.
I think this error will also occur if panorama.cgi doesn’t have it’s special permissions set up.
Are you saying that one client doesn’t work, and all of the others do? That’s weird. The error you are describing is definitely a server issue and I would expect it to occur for all clients, at least any client using TCP/IP. Perhaps some clients are using AppleEvents and others are using TCP/IP?
You haven’t mentioned anything about what OS version is running on either the client or the server. The steps necessary for getting Panorama Server running changed quite a bit from 10.6 to 10.10, so I can’t hand out any “one size fits all” advice. There were some extensive discussions about this on the Panorama QNA forum 2-3 years ago.
Yes, I have several clients machines connecting fine but 1 is getting the Server is not running as described.
Server OS: 10.6.8.
Client OS: 10.11.6
I was presuming that all clients would be connecting in an identical way as prescribed by the server. I did attempt both TCP/IP as well as AppleEvents by selecting each type in the pop down on the server. Details as noted in the previous post.
Update… The problematic client is connecting fine today. Argh. O well.
Is ServerConfig.dat normally backed up as part of any backup process? Is there much history of it getting corrupted?
Hmmm. Apparently the problematic client computer is now taking down the server when particular files are being loaded. New copies of those problematic files are being downloaded which may hopefully resolve future crashes.
ServerConfig.dat is just a text file inside the Panorama folder. If the Panorama folder is getting backed up, it is also getting backed up.
I’ve never heard of this file being corrupted, but there is always a first time. It is just a text file, you can open it or even edit it with BBEdit, TextWrangler, etc. Maybe if you do that it will be obvious what the problem was.
I was presuming that all clients would be connecting in an identical way as prescribed by the server.
There is a preference on the client side also that can override the server preference for this.