Website-Icon DOMUS Software AG

DOMUS 1000: Access wird nach Windows-/Office Updates langsam? Ursachen & Lösungen (Stand 12/2025)

In den letzten Wochen haben uns vermehrt Anfragen zu Performance- bzw. Laufzeitproblemen erreicht: Besonders betroffen sind Auswertungen, Sammler/Überweisungen und Eingaben in dialoglastigen Masken.

Dieser Beitrag erklärt die wahrscheinlichsten Ursachen und führt durch konkrete Maßnahmen, die gemeinsam mit Ihrem technischen Ansprechpartner sicher und nachvollziehbar umgesetzt werden können.

TL;DR – Schnellüberblick

1) Symptome richtig deuten

Typische Anzeichen aus der Praxis:

Folgerung: Der Flaschenhals liegt meist im Netzwerk‑/Protokoll‑Stack plus Dateifreigabe‑I/O, nicht in der Anwendung selbst.

2) Die häufigsten Ursachen (einfach erklärt)

  1. Erzwungene SMB‑Signierung (ab 24H2/Server 2025)\ Jede SMB‑Nachricht wird kryptografisch signiert. Bei Access entstehen sehr viele kleine, synchrone Datei‑Operationen – der zusätzliche Overhead macht sich stark bemerkbar.
  2. TCP‑Profil „Internet“ auf LAN‑Verbindungen\ Windows nutzt TCP‑Templates; Datacenter ist für niederlatente LANs optimiert, Internet für höhere Latenzen. Wenn LAN‑Flows fälschlich mit Internet laufen, kommen unnötige Verzögerungen hinzu.
  3. AV/EDR‑On‑Access‑Scan\ Virenschutz prüft *.accdb/*.laccdb auf dem Share in Echtzeit – jeder Lock/Unlock und jede kleine I/O wird gebremst.
  4. WLAN‑Latenz/Treiber\ Bestimmte WLAN‑Treiber/Builds erhöhen Latenz/Jitter. Access reagiert empfindlich.
  5. Access‑Design & Optionen\ Gemeinsames Frontend auf dem Share, Subdatasheets, AutoNameCorrect, fehlende Indizes, fehlende persistente Backend‑Verbindung – alles Faktoren, die Netzwerk‑I/O verstärken.

3) Schritt für Schritt – Diagnose & Maßnahmen

Wichtig: Änderungen immer dokumentieren und auf ein bis zwei Referenz‑Clients testen. Für heikle Tests (SMB‑Signierung) ausschließlich im vertrauenswürdigen LAN und nur kurzzeitig.

Schritt 1 – Basismessung (Pflicht)

Ablauf

  1. Ist‑Zustand messen: Einen betroffenen Vorgang (z. B. Sammler erstellen/aktivieren) mit Stoppuhr messen – Backend auf dem Netzlaufwerk.
  2. Kontrolltest lokal: Backend testweise lokal auf den Client kopieren, gleiches Szenario messen.
  3. Vergleichen: Ist lokal deutlich schneller, ist der Netz‑/Protokoll‑Stack der Hauptkandidat.

Schritt 2 – Offensichtliche Bremsen ausschließen

Schritt 3 – TCP‑AppliedSetting prüfen

PowerShell (als Administrator):

Get-NetTCPConnection |

Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,AppliedSetting |

Sort-Object AppliedSetting -Descending

Schritt 4 – SMB‑Signierung nur testen, nicht abschalten

Sicherheits‑Hinweis: SMB‑Signierung schützt vor Manipulation/Relay. Dauerhaftes Abschalten ist nicht empfehlenswert. Der folgende Schritt dient ausschließlich zum Kurztest mit direktem Rückbau.

Clientseitig temporär lockern (nur Test, Trusted LAN):

# Signierung NICHT erforderlich (Test!)

reg add “HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters” ^

/v RequireSecuritySignature /t REG_DWORD /d 0 /f

 

net

# Signierung wieder ERFORDERLICH

reg add “HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters” ^

/v RequireSecuritySignature /t REG_DWORD /d 1 /f

 

net stop workstation & net start workstation

Interpretation:

Schritt 5 – TCP‑Handling gezielt optimieren (nur Windows 10/11, keine Server)

Nur mit Wiederherstellungspunkt/Backup der ursprünglichen Einstellungen arbeiten.

  1. a) AppliedSetting beeinflussen (konservativ)\ Ziel: Für LAN‑Workloads das Datacenter‑Profil verfügbar machen.

# Aktuelle TCP-Settings anzeigen

Get-NetTCPSetting

 

# Optional: ECN aktivieren (vorsichtig, nur wenn keine Altgeräte stören)

netsh int tcp set global ecn=enabled

 

# Datacenter-Custom bereitstellen (falls nicht vorhanden) und DCTCP setzen

netsh int tcp set supplemental template=Datacenter congestionprovider=DCTCP

net

Hinweis: Welche Templates effektiv greifen, entscheidet Windows dynamisch (RTT u. a.). Ziel ist, Datacenter‑Parameter für LAN sicher verfügbar zu machen. Nach einem Neustart erneut Get‑NetTCPConnection prüfen.

  1. b) Optional: Offload‑Features prüfen\ Bei manchen NICs lohnt es, RSS/RSC/EEE/Interrupt Moderation testweise zu deaktivieren und zu messen. Das ist treiber‑ und umgebungsabhängig:

# Beispielhaft – erst auf EINEM Test-Client probieren

netsh int tcp set global RSS=disabled

netsh int tcp set global RSC=disabled

 

# Energiesparfunktionen der NIC abschalten (Bezeichnungen variieren je Hersteller)

Get-NetAdapter -Physical | Set-NetAdapterAdvancedProperty -RegistryKeyword “*EEE” -RegistryValue 0

Get

Danach Neustart und Messung. Falls keine Verbesserung: Änderungen zurücknehmen.

4) Access‑Best‑Practices (sofort wirksam)

5) Nachhaltige Lösungen

6) Kompakte Checkliste

  1. Ist vs. lokal: Vorgang auf Share messen, dann mit lokalem Backend gegenprüfen.
  2. Schnelle Bremsen: LAN statt WLAN, Standarddrucker auf Microsoft PDF, AV‑Ausnahmen setzen, NIC‑Treiber aktualisieren.
  3. TCP‑AppliedSetting prüfen (Get‑NetTCPConnection).
  4. SMB‑Signierung kurz testen (Trusted LAN, sofort zurückbauen).
  5. TCP‑Handling konservativ optimieren (Datacenter/DCTCP/ECN – nur Client‑OS, mit Rollback).
  6. Access‑Best‑Practices: Lokales FE, persistente Verbindung, Indizes/Optionen, Kompakt/Reparatur.

 

Die mobile Version verlassen