• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question "We have detected a compatibility issue"

greybeard

New Pleskian
Server operating system version
Windows Server 2016 Standard
Plesk version and microupdate number
Plesk Obsidian Version 18.0.49 Update #2, last updated on Jan 11, 2023 04:28 AM
I specialize in hosting stores built upon a particular shopping cart. It is coded, for the most part, in classic ASP. There is some .NET code that plays a role in encoding passwords.

These stores require very specific settings - nothing complicated, but you have to get them right. .NET has to be configured (along with ASP), 32-bit must be enabled, and the application pool must be "integrated". Not a big deal.

In July of last year I discovered that a site which had been present on the server since Sept 2020 would no longer play nice - we could no longer log in to the store admin. The error we received was "We have detected a compatibility issue", which is typically an indication that the above server settings are hosed. I reset the settings over and over, confirming them both via IIS as well as via Plesk. Could not resolve the issue any other way than moving the site to another server where it runs at the present time...

Fast forward to 2 weeks ago, and another site has revealed the same symptoms. I created a dev subdomain, established all of the same settings, copied the files over, and it works just fine. In the original domain, I have reversed and reset all of the needed settings (more than once) and it still failed. Nothing I am aware of had changed before this turned up, and I'm the only person responsible for any changes.

Today I created the domain over on the other server, pointed DNS to that copy of the site via an edit to the hosts file, and it works just fine (as expected.)

So I'm stuck. I don't want to keep having to interrupt stores and move them to a different server when they suddenly fail. How might I determine what has caused these two sites to stop properly running, despite there being no evidence of an incorrect setting?
 
Obvious question but have you tried looking over logs? Could probably start off looking at event viewer and the IIS log files.

Also was there any recent Windows Updates that was installed? Tried removing those updates?
 
@scsa20 Good morning - yes, I did look at the logs. There is a common .aspx file in this software which is receiving a 403 error. That's not untypical in a case where the application pool is not correctly configured. But I have a Word document into which I have pasted screenshots comparing the site that is failing, and the dev subdomain that works, to ensure I didn't miss a setting. I also compared to other sites that are working. The settings appear to be identical. I've spent over a week reviewing the settings and changing things back and forth in case there was some mismatch between IIS and Plesk.

That particular server contains 7 sites of the store code version that requires these settings. All of them work fine with the exception of the one I am dealing with. So if this were a matter of some Windows incompatibility issue, I would believe that all of those sites would be down instead of just one. Do you disagree? I appreciate your input.
 
I mean... it's Windows, so anything can happen.

And since you're getting a 403 error, that could also be permissions related. Either the permissions is different in terms of preventing IIS from reading the file or there's an antivirus program stopping it (I know there was plenty of time Cylance would decide that this one IIS site is no longer allow to function correctly because the the engine changes in one of their updates forcing us to downgrade that agent to allow IIS to function again until we found out what the changes was and what we needed to add to allow IIS to function).
 
I mean... it's Windows, so anything can happen.

And since you're getting a 403 error, that could also be permissions related. Either the permissions is different in terms of preventing IIS from reading the file or there's an antivirus program stopping it (I know there was plenty of time Cylance would decide that this one IIS site is no longer allow to function correctly because the the engine changes in one of their updates forcing us to downgrade that agent to allow IIS to function again until we found out what the changes was and what we needed to add to allow IIS to function).
 
Just double-checked - full permissions on the store folder. And in this particular subscription, there are 3 installs. Their original site, the one that is failing, and the dev subdomain that I created to determine if the problem was replicated. The original and dev subdomain run fine. I've compared all settings between the domains and they match. And yeah, Windows... I get it... Grrr...

I need to talk to my data center support about the possibility of your anti-virus concern.
 
Back
Top