Fejlfinding af problemer med klientforbindelse

Find først det fejlende stadie

En offline enhed kan skyldes den forkerte pakke, en stoppet tjeneste, et utilgængeligt slutpunkt eller en serverfejl. En tilsluttet enhed med en tom rapport er et andet symptom. Gennemgå kontrollerne nedenfor i rækkefølge, og registrer, hvad der ændrer sig.

Start med ét berørt slutpunkt. Registrer tidspunkt, implementeringsmodel, pakkeversion, operativsystem, forventet organisation og synlig fejl. Hold adgangskoder, forbindelsesstrenge, licens-id'er og private enhedsoplysninger ude af offentlige skærmbilleder.

1. Bekræft pakken og servicen

Bekræft, at du har installeret Agent i stedet for Admin eller Portable, og at dens Cloud- eller On-Premise-implementering matcher organisationen. I Windows Services skal du markere GoMyid for en cloudagent eller GoMyit for en lokal agent.

Hvis tjenesten mangler, skal du kontrollere installationsresultatet og beskyttelseshistorikken. Hvis den starter og derefter stopper, skal du registrere den relevante Windows hændelse og pakkefejl, før du geninstallerer den igen. Du må ikke ændre tjenestekontoen, og du må ikke deaktivere slutpunktsbeskyttelse som en første reaktion.

2. Bekræft den konfigurerede destination

For On-Premise skal du sammenligne pakkeslutpunktet med det tildelte serverværtsnavn eller IP-adresse. Et værtsnavn skal fortolkes korrekt fra den berørte enhed, inklusive dens VPN- eller filialnetværk. Et værtsnavn, der fungerer på selve serveren, fortolkes muligvis ikke på samme måde på en klient.

Hvis organisationen eller slutpunktet er forkert, skal du få fat i en korrekt genereret pakke via den godkendte opsætningsproces. Kopier ikke manuelt en anden kundes konfiguration.

3. Test den faktiske TCP-lytter

Spørg implementeringsadministratoren om den aktive serverport. Fra den berørte Windows -enhed kan en PowerShell forbindelseskontrol hjælpe med at adskille en netværksfejl fra en programfejl:

Test-NetConnection -ComputerName <server-hostname> -Port <configured-port>

Erstat begge pladsholdere, før du kører kommandoen. Hvis TcpTestSucceeded Hvis det er falsk, skal du kontrollere DNS, routing, VPN, serverlytteren og de firewallregler, der er omfattet af scopet. Hvis det er sandt, skal du fortsætte med at kontrollere programkonfigurationen og -organiseringen; TCP-succes beviser ikke tilmelding eller godkendelse.

4. Tjek serveren og databasen

For On-Premise skal du bekræfte, at serveren kører og lytter på den forventede grænseflade. Gennemgå opstarts- eller forbindelsesfejl, og verificer dens databaseforbindelse ved hjælp af den faktiske runtime-identitet. En manglende eller utilgængelig Sql.udl Filen kan påvirke den native server, selv når SQL er tilgængelig for en databaseadministrator.

Tjek GoMyidServer og GoMyidCore separat fra endpoint Agent . Opsætningen tester både login- og registrerings-/databasesiderne. Et loginsvar alene beviser ikke, at databasen fungerer. Se illustreret opsætningsgennemgang.

5. Skeln mellem manglende rapporter og manglende forbindelser

Hvis enheden er tilsluttet, men en rapport er tom, skal du verificere den valgte organisation, gruppe, bruger, datointerval, korrekturlæsertilladelser og aktiverede indsamlingsindstillinger. Tag højde for det konfigurerede indsamlingsinterval, og sammenlign en nylig kendt hændelse. Fortolk ikke en tom, filtreret rapport som bevis på, at installationen mislykkedes.

Reference til symptomkontrol

Hvad skal sendes til support

Send udgivelses- og pakketype, Windows version, tidsstempel med tidszone, nøjagtig fejl, servicetilstand, om DNS- og TCP-tjek lykkedes, og rensede relevante logfiler. Inkluder hvilket trin der sidst virkede. Del kun organisationsspecifikke identifikatorer via den godkendte private supportkanal.