Kända problem

Chrome-enheter

Chrome-enheten accepterar inte rätt lösenord

Känt problem:

Vi har fått rapporter om att vissa användare inte kan logga in på den hanterade Chrome-enheten, även när de använder rätt lösenord.

Vi har också fått rapporter om att vissa Chrome-kiosker vid start visar upp Chrome-inloggningssidan istället för att automatiskt starta sina appar.

Åtgärder för att lösa problemet:

Här är de två metoder som användare har angett löser dessa problem:

  • Ta bort användarkontot från Chrome-enheten och återskapa användarkontot på den berörda enheten. Försök sedan att logga in på Chrome-enheten.
  • Om det misslyckas, rensa och återregistrera Chrome-enheten.

Vi tittar aktivt på dessa problem och kommer inom kort att uppdatera det här kända problemet med mer detaljerad information.

 

Senast uppdaterad: 19 september 2018

Felmeddelandet Det gick inte att få ett registreringscertifikat

Felmeddelande: Det gick inte att få ett registreringscertifikat

Du ser detta felmeddelande när tvingad återregistrering har aktiverats på en Chrome-enhet. Det här felet uppstår när automatisk återregistrering misslyckas eftersom enheten är ansluten till ett nätverk med SSL-inspektion som inte har värdnamnet ”chromeos-ca.gstatic.com” vitlistat.

Lösning:

Användare kan växla till den manuella återregistreringsskärmen genom att klicka på X i det övre högra hörnet av felskärmen. Eller också kan administratören vitlista värdnamnet chromeos-ca.gstatic.com på proxyservern så att Chrome-enheter automatiskt kan registreras igen.

Vissa Chromebook-batterier laddas inte upp efter långvarig lagring

 Lithium-ionbatterier dräneras vanligtvis långsamt när de lämnas oladdade under långa perioder (exempelvis under skollov). Chromebook-modellerna nedan kan ladda ur så djupt under lagring så att batteriets laddningsförmåga påverkas:  
  • CTL J2/J4 Chrome for Education-enhet
  • CDI eduGear Chromebook K Series
  • HiSense Chromebook 11
  • Poin2 Chromebook 11

Mer information om hur du lagrar dessa enheter under en längre tid finns i Långtidslagring av Chromebooks.

Begränsning av antalet sparade dolda SSID-nätverk som en Chrome-enhet kan skanna och ansluta till

Antalet manuellt sparade och hanterade dolda SSID-nätverk som en Chrome-enhet kan skanna och ansluta till begränsas av vad WLAN chipset har stöd för, vilket kan variera mellan olika Chrome-modeller.

Detta kan verifieras på en Chrome-enhet i utvecklingsläge med följande kommando:

$ /usr/sbin/iw phy | grep -i ssid

Ett exempel på detta är att om kommandot anges på en Acer Chromebook C720 sker följande:

$ /usr/sbin/iw phy | grep -i ssid
        max # scan SSIDs: 4

I det här exemplet med en C720 är svaret 4. En konsumeras av skanningen och därför bör det finnas maximalt tre dolda SSID-nätverk sparade på enheten, antingen via en hanterad nätverkspolicy eller manuellt tillagada.

Vi uppmuntrar kunderna att inte använda dold SSID för sina åtkomstpunkter.

Viktigt! Markera dessa fall med crbug.com/577993 - "FR: Stöd för fler dolda SSID än maskinvaran har stöd för".

Felmeddelandet Kontrollerar enhetskonfiguration

Om skärmen fastnar och meddelandet Kontrollerar enhetskonfiguration visas när du konfigurerar en Chromebook kan det hända att du måste starta om systemet.

  1. Tryck ned strömbrytaren till Chromebook stängs av.
  2. Starta Chromebook igen.

Om felmeddelandet fortfarande visas kontaktar du Googles support.

Kiosk

Felmeddelandet ”Systemet repareras. Vänta.”

Om din skärm låser sig på meddelandet ”Systemet repareras. Vänta.” när du startar enheten kan det vara fel på maskinvaran. Du kan behöva byta ut enheten.

Om du misstänker att det finns berörda enheter i organisationen öppnar du ett supportärende hos oss.

Chrome-kiosken startar inte. Jag ser inloggningsskärmen istället.

Känt problem:

Vi har fått rapporter om att vissa Chrome-kiosker vid start visar upp Chrome-inloggningssidan istället för att automatiskt starta sina appar.

Åtgärder för att lösa problemet:

Här är en metod som vissa användare har angett löser detta problem:

Vi tittar aktivt på Detta problem och kommer inom kort att uppdatera det här kända problemet med mer detaljerad information.

 

Senast uppdaterad: 19 september 2018

Anpassade policyer för kioskapp gäller inte

 Om dina policyer för appar inte tillämpats när du har lagt till en ny kioskapp väljer du appen från listan Starta kioskapp automatiskt i inställningarna för kiosk med en app.

Ett Google Dokument-fel visas i Chrome Sign Builder när jag lägger till en Google-presentation och konfigurerar inställningar med Öppna presentationsalternativ

När du lägger till webbadressen för presentationer i fönstret Lägg till nytt innehåll i Chrome Sign Builder ska du inte klicka på Öppna presentationsalternativ. Ändra istället nödvändiga inställningar i fönstret Publicera på webben i Google Presentationer och använd den publicerade URL:en. Mer information om den här lösningen finns i denna Chromium-bug.

Chrome for Work

Användare måste ange CAPTCHA-frågan för att kunna söka

Det här problemet kan uppstå om organisationen dirigerar alla sökförfrågningar via en enda IP med en proxy. Sök på Google kan identifiera dessa förfrågningar som potentiell skräppost och otillåten användning, vilket utlöser en CAPTCHA-fråga.

Så här försöker du åtgärda problemet:

  • Om du använder DefaultSearchProviderSuggestURL-policyn ändrar du webbadressen till {google: baseURL}complete/search?output=chrome&q={searchTerms}.
  • Kör en sökning efter skadlig kod i ditt nätverk.
  • Stoppa användarna från att använda Hola VPN.

Relaterade ämnen:

Fel: Certifikatobjektets alternativa namn saknas eller NET::ERR_CERT_COMMON_NAME_INVALID eller Anslutningen är inte privat

I webbläsaren Chrome kontrolleras under anslutningar för Transport Layer Security (TLS) att ett giltigt och betrott servercertifikat används för anslutningen till webbplatsen.

För Chrome 58 och senare används endast tillägget subjectAlternativeName (inte commonName) för att matcha domännamnet och webbplatsens certifikat. Certifikatobjektets alternativa namn kan vara ett domännamn eller en IP-adress. Om certifikatet inte har rätt subjectAlternativeName-tillägg får användarna felet NET::ERR_CERT_COMMON_NAME_INVALID, som visar att anslutningen inte är privat. När certifikatet saknar tillägget subjectAlternativeName visas i säkerhetspanelen i Chrome DevTools en varning för användarna om att certifikatobjektets alternativa namn saknas.

I vissa infrastrukturer för offentligt nyckelcertifikat och äldre versioner av programvara för nätverksövervakning används certifikat utan subjectAlternativeName-tillägg. Om det uppstår problem med någon av dessa kontaktar du programvaruleverantören eller administratören och ber om ett nytt certifikat.

För Microsoft® Windows® kan du använda PowerShell Cmdlet New-SelfSignedCertificate och ange parametern DnsName.

För OpenSSL kan du använda tillägget subjectAltName för att ange certifikatobjektets alternativa namn.

Du kan ange policyn EnableCommonNameFallbackForLocalAnchors upp till Chrome 65. Ett värdnamn kan då matchas i Chrome med certifikatet för commonName om tillägget subjectAlternativeName saknas i certifikatet.

Enhetshantering

Det går inte att återaktivera en inaktiverad Chrome-enhet

Om du har försökt att aktivera en enhet med Chrome OS men enheten förblir inaktiverad kontrollerar du serienumret.

Så här hittar du serienumret:

  1. Slå på enheten.

  2. Tryck på Alt + V innan du loggar in.

  3. Jämför serienumret som visas på skärmen med det tryckta serienumret på enheten. På vissa Chrome-enheter som har blivit restaurerade eller modifierade på annat sätt kanske serienumret på etiketten inte stämmer.

  4. Om serienumren inte stämmer är det tryckta numret på etiketten fel. Om du använder det tryckta serienumret vid aktiveringen misslyckas kommandot.

Förslag till åtgärd: Vi rekommenderar att du vänder dig till tillverkaren och ber dem att ersätta enheten med en annan. Om du fortsätter att använda enheten ska du använda serienumret som visas på skärmen (inte det som står på etiketten) vid hanteringen.

Mer information finns i Visa information om Chrome OS-enheter.

Användaren kan inte logga in trots att han eller hon har en godkänd policy för användarlista

Om användarna ser felmeddelanden vid inloggningen och anger att de inte får logga in på enheten på grund av en domänpolicy kan det bero på SSL-filtrering. Vi har nyligen uppdaterat listan över webbadresser som ska godkännas för SSL-filter, så granska och uppdatera webbadresserna för den här listan.
Var det här till hjälp?
Hur kan vi förbättra den?