MOSS 404-Fehler für einige Benutzer auf bestimmten Websites, manchmal

Question

Bei den meisten Konten funktioniert alles zu 100 %, aber hier und da erhalten einige Benutzer, die an einem Tag problemlos auf eine Unterseite zugreifen können, am nächsten Tag eine Standard-404-Meldung. Das kann eine Stunde oder zwei Tage dauern, es ist wirklich uneinheitlich.

Ich überprüfe die iis-Protokolle und stelle fest, dass der Status für diese Anfragen ebenfalls 404 ist, sonst sieht nichts ungewöhnlich aus. In den Sharepoint-Protokollen steht auch nichts über die Zeitstempel.

Korrigieren Sie mich, wenn ich falsch liege, aber wenn es sich um ein Berechtigungsproblem handeln würde, würde eine Meldung "Zugriff verweigert" angezeigt werden.

Es ist nicht der einzelne Computer, denn wenn ein Benutzer dieses Problem hat und ich mich mit seinem Konto anmelden kann, erhalte ich auch die 404-Fehlermeldung, obwohl ich genau zur gleichen Zeit mit einem anderen Konto in einem anderen Browser auf der gleichen Website bin, und es funktioniert perfekt.

Für Vorschläge wäre ich sehr dankbar, ich habe viel gesucht, kann aber nirgendwo eine ähnliche Situation oder Hilfe finden.

Answer 1

Da die Informationen im Moment sehr knapp sind, werde ich ein paar Fragen stellen, die Sie auf das Problem aufmerksam machen könnten.

• Haben wir einen Ladeausgleich? Die intermittierenden 404 können dadurch verursacht werden, dass einer der Web FrontEnds des Servers die Anfragen nicht korrekt bedient.
• Geht der Speicherplatz auf dem SQL Server-Rechner zur Neige? Dies könnte die Ursache sein
• Sind der Blogcache oder die Website-Caches aktiviert? Einige Routinen können sie unterbrechen
• Haben wir Anti-Virus auf dem Server? (es MUSS gefragt werden :p)
• Wir erhalten sehr hohe Paketverluste zwischen den Servern? (Der Fehler wäre allerdings ein anderer)

Etwas, das sehr oft vorkommen kann, ist, wenn Sie, sagen wir, benutzerdefinierten Code eine DLL auf dem GAC oder dem BIN-Ordner haben, und da Sie auf dem Ladegleichgewicht sein könnten, hat der zweite Server diese DLL nicht in seinem eigenen GAC oder BIN-Ordner. Sharepoint gibt in der Regel 404s aus, wenn Assemblies nicht gefunden werden, nicht nur Anfragen.

Answer 2

Dies scheint eine weit hergeholte Vermutung zu sein, aber... könnten diese SharePoint-Sites eine 404 HttpException auslösen? Es scheint, als würden Sie das auch in den SharePoint-Protokollen sehen, also ist es noch unwahrscheinlicher.

Ist Ihre SharePoint-Protokollierungsstufe auf jeden Fall auf eine angemessene ausführliche Stufe eingestellt, um solche merkwürdigen Dinge zu debuggen?

Answer 3

Werden Änderungen an der Hauptseite eingecheckt und veröffentlicht, wenn neue CSS-Dateien und/oder andere Includes (Skriptdateien usw.) noch gar nicht veröffentlicht sind? Ich habe schon einige Male erlebt, dass dies zu einem 404 führt, wenn Benutzer vergessen, dies vor der Veröffentlichung zu überprüfen.

Answer 4

Ich musste benutzerdefinierten Code in einem SharePoint-Kontext schreiben und hatte ebenfalls diese 404-Fehler. Die Lösung bestand in meinem Fall darin, sicherzustellen, dass der Codeblock, der ausgeführt wird, die folgenden 2 Bedingungen erfüllt:

1) Führen Sie das Programm mit erhöhten Rechten aus, unabhängig davon, dass es sich um eine 404 handelt, war dies Teil der Lösung.

2) web.AllowUnsafeUpdates = true; Diese Codezeile musste hinzugefügt werden, obwohl sie in einen Block mit erhöhten Rechten eingeschlossen war.

Sobald diese hinzugefügt wurden, trat das Problem nicht mehr auf. Dies geschah sowohl in Umgebungen mit als auch ohne Lastausgleich.

Answer 5

Dies erinnert mich an einen seltsamen asp.net-Fehler, den ich vor ein paar Monaten hatte. Er wurde durch einen Patch verursacht, der angewendet wurde (auf das Framework, wenn ich mich richtig erinnere)

Versuchen Sie, dies herunterzuladen Werkzeug für die Windows-Update-Liste und sehen Sie sich an, was sich seit dem Auftreten des Problems geändert hat.

Ich räume ein, dass es sich bei einem Problem mit einem Patch eher um einen konsistenten Fehler handeln würde, aber es ist einen Blick wert.