Dela via

Felsökningsguide för DirectAccess

Prova vår virtuella agent – Det kan hjälpa dig att snabbt identifiera och åtgärda vanliga DirectAccess-problem.

Den här guiden innehåller felsökningsinformation för DirectAccess på Windows-operativsystem. Den är utformad för att hjälpa dig att identifiera och lösa problem som är relaterade till DirectAccess.

Checklista för felsökning

Uppdaterad

Håll DirectAccess-servrar och DirectAccess-klientenheter uppdaterade. Du måste regelbundet uppdatera Windows, drivrutiner, inbyggd programvara, komponenter för Hyper-V-integreringar och VMware-verktyg. Om det är tillämpligt måste du också uppdatera hypervisor-programmet som kör de virtuella datorerna.

OS-version

Använd en aktuell version av operativsystemet: minst Windows Server 2016 eller Windows Server 2019 för DirectAccess-servrarna. DirectAccess-klienter bör köra en ny version av Windows 10 eller Windows 11.

Monitor

Använd övervakning för DirectAccess-servrarna. Övervaka i alla fall följande mått:

  • CPU-användning
  • Minnesanvändning
  • Diskprestanda
  • Ledigt diskutrymme
  • Tillgänglighet för nätverkskort
  • Nätverkskortets dataflöde och NetNat-portar.

Behåll också en historik över prestandarapportering. Rapporteringen kan vara användbar när du felsöker prestandarelaterade problem.

Infrastrukturkomponenter

DirectAccess förlitar sig på perimeter- eller interna brandväggar, lastbalanserare, routrar, växlar och så vidare. Dessa bör också övervakas. Om en lastbalanserare till exempel har nått sin kapacitet påverkar detta DirectAccess. Från ett DirectAccess-perspektiv finns det dock inte mycket du kan göra för att åtgärda den här situationen.

Backup

DirectAccess lagrar alla inställningar i grupprinciper. Det är viktigt att du upprätthåller en aktuell och giltig säkerhetskopia av alla DirectAccess-grupprincipinställningar.

Bästa praxis

Storleks- och kapacitetsplanering

Den bästa felsökningsmetoden är metoden "inkrementell ramp, test och monitor". Antalet DirectAccess-servrar är mycket beroende av vad användarna gör. Detta omfattar användning av klient- eller serverprogram, surfning på interna webbplatser och arbete med eller kopiering av stora filer (till exempel CAD-filer).

En bra utgångspunkt är att använda minst fyra processorer och mer än åtta gigabyte (GB) RAM-minne. Ett bättre alternativ är åtta processorer, mer än 12 GB RAM-minne och mer än 80 GB diskutrymme. Det finns ingen programmatisk preferens för fysiska eller virtuella servrar. Båda fungerar bra om de har rätt storlek.

Mer information finns i Kapacitetsplanering för DirectAccess.

Gräns

Det finns ingen känd gräns för hur många anslutningar en DirectAccess-server kan acceptera, förutom resursbegränsningar (CPU, minne, diskutrymme, nätverksdataflöde och så vidare) och NetNat-portar (NAT64).

NetNat (NAT64) används på DirectAccess-servrar för översättning mellan IPv6 och IPv4. Som standard finns det 40 999 (6001-49000) NetNat-portar tillgängliga när du använder en enda IP-adress på det interna nätverkskortet.

Kommentar

Antalet aktiva DirectAccess-anslutningar är inte nödvändigtvis relaterade till antalet NetNat-portar som används. Ett litet antal DirectAccess-klienter kan få slut på alla NetNat-portar, beroende på vad användarna gör och hur många portar som används av en DirectAccess-klient.

Du kan visa NetNat-konfigurationen genom att köra kommandot Get-NetNatTransitionConfiguration.

Kända problem och lösningar

I följande artiklar kan du felsöka problem med DirectAccess-serverkonsolen:

Datainsamling

Innan du kontaktar Microsofts support kan du samla in information om problemet.

Förutsättningar

  1. TSS måste köras av konton med administratörsprivilegier i det lokala systemet, och serviceavtalet måste godkännas (när licensavtalet har godkänts uppmanas inte TSS igen).
  2. Vi rekommenderar den lokala datorns RemoteSigned PowerShell-körningsprincip.

Kommentar

Om den aktuella PowerShell-körningsprincipen inte tillåter körning av TSS vidtar du följande åtgärder:

  • RemoteSigned Ange körningsprincipen för processnivån genom att köra cmdleten PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned.
  • Kontrollera om ändringen börjar gälla genom att köra cmdleten PS C:\> Get-ExecutionPolicy -List.
  • Eftersom behörigheterna på processnivå endast gäller för den aktuella PowerShell-sessionen, när det angivna PowerShell-fönstret där TSS körs stängs, återgår även den tilldelade behörigheten för processnivån till det tidigare konfigurerade tillståndet.

Samla in viktig information innan du kontaktar Microsofts support

  1. Ladda ned TSS på alla noder och packa upp den i mappen C:\tss.

  2. Öppna mappen C:\tss från en upphöjd PowerShell-kommandotolk.

  3. Starta spårningarna på klienten och servern med hjälp av följande cmdletar:

    Kommentar

    Om du använder ett NLB-scenario startar du loggarna på alla servrar.

    • DA-klient:

      TSS.ps1 -Scenario NET_Dacli

    • DA-server:

      TSS.ps1 -Scenario NET_DAsrv

  4. Godkänn serviceavtalet om spårningarna körs för första gången på servern eller klienten.

  5. Tillåt inspelning (PSR eller video).

  6. Återskapa problemet innan du anger Y.

    Kommentar

    Om du samlar in loggar på både klienten och servern väntar du på det här meddelandet på båda noderna innan du återskapar problemet.

  7. Ange Y för att slutföra loggsamlingen när problemet har återskapats.

Spårningarna lagras i en zip-fil i mappen C:\MS_DATA , som kan laddas upp till arbetsytan för analys.

Referens