Dela via


Felsöka push-installation för mobilitetstjänsten

Installationen av tjänsten Mobility ett viktigt steg för att aktivera replikering. Det här steget kräver att förhandskraven är uppfyllda och att kompatibla konfigurationer används. De vanligaste felen du kan stöta på under installationen av tjänsten Mobility beror på:

När du aktiverar replikering försöker Azure Site Recovery installera tjänsten Mobility-agenten på den virtuella datorn (VM). Som en del av den här processen försöker konfigurationsservern ansluta till den virtuella datorn och kopiera agenten. Om du vill aktivera en lyckad installation följer du den stegvisa felsökningsguiden.

Autentiseringskontroll (ErrorID: 95107 & 95108)

Kontrollera att det användarkonto som valdes under aktivering av replikering är giltigt och korrekt. Azure Site Recovery kräver att rotkontot eller användarkontot med administratörsbehörighet utför en push-installation. Annars blockeras push-installationen på källdatorn.

För Windows (fel 95107) kontrollerar du att användarkontot har administrativ åtkomst på källdatorn, antingen med ett lokalt konto eller ett domänkonto. Om du inte använder ett domänkonto måste du inaktivera fjärranvändaråtkomstkontroll på den lokala datorn.

  • Så här lägger du till en registernyckel manuellt som inaktiverar åtkomstkontroll för fjärranvändare:

    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
    • Lägg till en ny DWORD: LocalAccountTokenFilterPolicy
    • Ange värdet till 1
  • Om du vill lägga till registernyckeln kör du följande kommando från en kommandotolk:

    REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1

För Linux (fel 95108) måste du välja rotkontot för lyckad installation av tjänsten Mobility agent. Dessutom bör SSH File Transfer Protocol-tjänster (SFTP) köras. Så här aktiverar du SFTP-undersystemet och lösenordsautentiseringen i sshd_config-filen:

  1. Logga in som rot.
  2. Gå till filen /etc/ssh/sshd_config och leta reda på raden som börjar med PasswordAuthentication.
  3. Ta bort kommentaren till raden och ändra värdet till yes.
  4. Hitta raden som börjar med Subsystemoch ta bort kommentaren till raden.
  5. sshd Starta om tjänsten.

Om du vill ändra autentiseringsuppgifterna för det valda användarkontot följer du dessa instruktioner.

Otillräckligt behörighetsfel (ErrorID: 95517)

När användaren har valt att installera Mobilitetsagenten har inte administratörsbehörighet, kommer konfigurationsservern/utskalningsprocessens server inte att tillåtas kopiera mobilitetsagentens programvara till källdatorn. Det här felet beror på ett fel med nekad åtkomst. Kontrollera att användarkontot har administratörsbehörighet.

Om du vill ändra autentiseringsuppgifterna för det valda användarkontot följer du dessa instruktioner.

Otillräckligt behörighetsfel (ErrorID: 95518)

När etableringen av domänförtroenderelationen mellan den primära domänen och arbetsstationen misslyckas när du försöker logga in på källdatorn misslyckas installationen av Mobilitetsagenten med fel-ID 95518. Kontrollera att det användarkonto som används för att installera Mobilitetsagenten har administratörsbehörighet för att logga in via källdatorns primära domän.

Om du vill ändra autentiseringsuppgifterna för det valda användarkontot följer du de här anvisningarna.

Inloggningsfel (ErrorID: 95519, 95520, 95521, 95522)

I det här avsnittet beskrivs felmeddelanden för autentiseringsuppgifter och inloggning.

Autentiseringsuppgifterna för användarkontot har inaktiverats (ErrorID: 95519)

Det användarkonto som valdes under aktivering av replikering inaktiverades. Om du vill aktivera användarkontot läser du den här artikeln eller kör följande kommando genom att ersätta textanvändarnamnet med det faktiska användarnamnet.

net user 'username' /active:yes

Autentiseringsuppgifter utelåst på grund av flera misslyckade inloggningsförsök (ErrorID: 95520)

Flera misslyckade försök att komma åt en dator låser användarkontot. Felet kan bero på:

  • Autentiseringsuppgifterna som angavs under konfigurationskonfigurationen är felaktiga.
  • Det användarkonto som valdes under aktiveringsreplikeringen är fel.

Ändra de autentiseringsuppgifter som valts genom att följa dessa instruktioner och försök igen.

Inloggningsservrar är inte tillgängliga på källdatorn (ErrorID: 95521)

Det här felet uppstår när inloggningsservrarna inte är tillgängliga på källdatorn. Om inloggningsservrar inte är tillgängliga misslyckas inloggningsbegäranden och mobilitetsagenten kan inte installeras. För en lyckad inloggning kontrollerar du att inloggningsservrar är tillgängliga på källdatorn och startar Netlogon-tjänsten. Mer information finns i Windows-inloggningsscenarier.

Inloggningstjänsten körs inte på källdatorn (ErrorID: 95522)

Inloggningstjänsten körs inte på källdatorn och orsakade fel i inloggningsbegäran. Mobilitetsagenten kan inte installeras. Lös felet genom att använda någon av följande metoder för att starta Netlogon tjänsten på källdatorn:

  • Netlogon Starta tjänsten från en kommandotolk genom att köra kommandot net start Netlogon.
  • Starta tjänsten från Aktivitetshanteraren Netlogon .

Anslut ivity failure (ErrorID: 95117 & 97118)

Konfigurationsserver/utskalningsprocessserver försöker ansluta till den virtuella källdatorn för att installera Mobilitetsagenten. Det här felet uppstår när källdatorn inte kan nås eftersom det finns problem med nätverksanslutningen.

Så här åtgärdar du felet:

  • Kontrollera att användarkontot har administrativ åtkomst på källdatorn, med antingen ett lokalt konto eller ett domänkonto. Om du inte använder ett domänkonto måste du inaktivera fjärranvändaråtkomstkontroll på den lokala datorn.

    • Så här lägger du till en registernyckel manuellt som inaktiverar åtkomstkontroll för fjärranvändare:

      • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
      • Lägg till en ny DWORD: LocalAccountTokenFilterPolicy
      • Ange värdet till 1
    • Om du vill lägga till registernyckeln kör du följande kommando från en kommandotolk:

      REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1

  • Kontrollera att du kan pinga källdatorn från konfigurationsservern. Om du har valt utskalningsprocessservern under aktivering av replikering kontrollerar du att du kan pinga källdatorn från processervern.

  • Kontrollera att fil- och skrivardelningstjänsten är aktiverad på den virtuella datorn. Kontrollera stegen här.

  • Kontrollera att WMI-tjänsten är aktiverad på den virtuella datorn. Kontrollera stegen här.

  • Kontrollera att de delade nätverksmapparna på den virtuella datorn är tillgängliga från processervern. Kontrollera stegen här.

  • Från kommandoraden för konfigurationsservern eller utskalningsprocessen använder du Telnet för att pinga den virtuella källdatorn på port 135 enligt följande kommando. Det här kommandot kontrollerar om det finns några problem med nätverksanslutningen eller om brandväggsporten blockerar problem.

    telnet <Source IP address> <135>

  • Dessutom för en virtuell Linux-dator:

    • Kontrollera om de senaste OpenSSH-, OpenSSH Server- och OpenSSL-paketen har installerats.

    • Kontrollera att Secure Shell (SSH) är aktiverat och körs på port 22.

    • SFTP-tjänster ska köras. Så här aktiverar du SFTP-undersystem och lösenordsautentisering i sshd_config-filen:

      1. Logga in som rot.
      2. Gå till filen /etc/ssh/sshd_config och leta reda på raden som börjar med PasswordAuthentication.
      3. Ta bort kommentaren till raden och ändra värdet till yes.
      4. Hitta raden som börjar med Subsystemoch ta bort kommentaren till raden
      5. sshd Starta om tjänsten.
  • Ett anslutningsförsök kan ha misslyckats om det inte finns några korrekta svar efter en viss tidsperiod, eller om en upprättad anslutning misslyckades eftersom en ansluten värd inte svarade.

  • Det kan vara ett anslutningsproblem/nätverk/domänrelaterat problem. Det kan också bero på att DNS-namn löser problem eller TCP-portöverbelastningsproblem. Kontrollera om det finns några sådana kända problem i din domän.

Anslut ivity failure (ErrorID: 95523)

Det här felet uppstår när det nätverk som källdatorn finns i inte hittas, kan ha tagits bort eller inte längre är tillgängligt. Det enda sättet att lösa felet är att se till att nätverket finns.

Kontrollera åtkomsten för delade nätverksmappar på källdatorn (ErrorID: 95105,95523)

Kontrollera om de delade nätverksmapparna på den virtuella datorn är tillgängliga från Process Server (PS) via fjärranslutning med angivna autentiseringsuppgifter. Så här bekräftar du åtkomsten:

  1. Logga in på processerverdatorn.

  2. Öppna Utforskaren. I adressfältet skriver du \\<SOURCE-MACHINE-IP>\C$ och klickar på Retur.

    Open folder in PS

  3. Utforskaren frågar efter autentiseringsuppgifter. Ange användarnamnet och lösenordet och klicka på OK.

    Provide Credentials

    Kommentar

    Om källdatorn är domänansluten anger du domännamnet tillsammans med användarnamnet som <domainName>\<username>. Om källdatorn finns i en arbetsgrupp anger du endast användarnamnet.

  4. Om anslutningen lyckas visas mapparna på källdatorn via fjärranslutning från processservern.

    Visible folders from Source Machine

Om anslutningen misslyckas kontrollerar du om alla förutsättningar uppfylls.

Kontroll av fil- och skrivardelningstjänster (ErrorID: 95105 & 95106)

Efter en anslutningskontroll kontrollerar du om fil- och skrivardelningstjänsten är aktiverad på den virtuella datorn. De här inställningarna krävs för att kopiera Mobilitetsagenten till källdatorn.

För Windows 2008 R2 och tidigare versioner:

  • Aktivera fil- och utskriftsdelning via Windows-brandväggen genom att

    1. Öppna windowsbrandväggen> Kontrollpanelen System och säkerhet.> I den vänstra rutan väljer du Avancerade inställningar>Inkommande regler i konsolträdet.
    2. Leta upp regler Fil- och skrivardelning (NB-Session-In) och Fil- och skrivardelning (SMB-In).
    3. Högerklicka på regeln för varje regel och klicka sedan på Aktivera regel.
  • Så här aktiverar du fildelning med grupprincip:

    1. Gå till Start, skriv gpmc.msc och sök.

    2. I navigeringsfönstret öppnar du följande mappar: Administratörsmallar för användarkonfiguration>av lokal dator>– Administrationsmallar>För Windows-komponenter>Nätverksdelning.

    3. Dubbelklicka på Förhindra användare från att dela filer i sin profil i informationsfönstret.

      Om du vill inaktivera grupprincipinställningen och aktivera användarens möjlighet att dela filer väljer du Inaktiverad.

    4. Spara ändringarna genom att välja OK.

    Mer information finns i Aktivera eller inaktivera fildelning med grupprincip.

Om du vill aktivera fil- och skrivardelning för senare versioner av Windows eller Linux följer du anvisningarna i Installera tjänsten Mobility för haveriberedskap för virtuella VMware-datorer och fysiska servrar.

Konfigurationskontroll av Windows Management Instrumentation (WMI) (felkod: 95103)

När fil- och skrivartjänster har kontrollerats aktiverar du WMI-tjänsten för privata, offentliga profiler och domänprofiler via brandväggen. De här inställningarna krävs för att slutföra fjärrkörningen på källdatorn.

Så här aktiverar du WMI:

  1. Gå till Kontrollpanelen> Säkerhet och välj Windows-brandväggen.
  2. Välj Ändra Inställningar och välj sedan fliken Undantag.
  3. I fönstret Undantag markerar du kryssrutan för Windows Management Instrumentation (WMI) för att aktivera WMI-trafik genom brandväggen.

Du kan också aktivera WMI-trafik via brandväggen från kommandotolken med följande kommando:

netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

Andra WMI-felsökningsartiklar finns i följande artiklar.

Operativsystem som inte stöds

En annan vanlig orsak till felet kan bero på ett operativsystem som inte stöds. Använd ett operativsystem och en kernelversion som stöds för en lyckad installation av tjänsten Mobility. Undvik att använda privata korrigeringar.

Information om hur du visar listan över operativsystem och kernelversioner som stöds av Azure Site Recovery finns i dokumentet om supportmatris.

Startdiskkonfigurationer som inte stöds (ErrorID: 95309, 95310, 95311)

Start- och systempartitioner/volymer är inte samma disk (ErrorID: 95309)

Innan 9.20-versionen var start- och systempartitioner/volymer på olika diskar en konfiguration som inte stöds. Från och med 9.20-versionen stöds den här konfigurationen.

Startdisken är inte tillgänglig (ErrorID: 95310)

Det går inte att skydda en virtuell dator utan en startdisk. En startdisk garanterar en smidig återställning av en virtuell dator under en redundansåtgärd. Avsaknad av en startdisk resulterar i ett fel när datorn startas efter redundansväxlingen. Kontrollera att den virtuella datorn innehåller en startdisk och försök igen. Dessutom stöds inte flera startdiskar på samma dator.

Flera startdiskar som finns på källdatorn (ErrorID: 95311)

En virtuell dator med flera startdiskar stöds inte.

Systempartition på flera diskar (ErrorID: 95313)

Före 9.20-versionen var en rotpartition eller volymkonfiguration på flera diskar en konfiguration som inte stöds. Från och med 9.20-versionen stöds den här konfigurationen.

Aktivera skydd misslyckades som enhetsnamn som nämns i GRUB-konfigurationen i stället för UUID (ErrorID: 95320)

Möjlig orsak

Grub-konfigurationsfilerna (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg eller /etc/default/grub) kan innehålla värdet för parametrarnas rot och återupptas som de faktiska enhetsnamnen i stället för en universellt unik identifierare (UUID). Site Recovery kräver UUID-metoden eftersom enhetsnamnen kan ändras vid omstart av den virtuella datorn. Den virtuella datorn kanske till exempel inte är online med samma namn vid redundansväxling och det resulterar i problem.

Till exempel:

  • Följande rad kommer från GRUB-filen /boot/grub2/grub.cfg:

    linux /boot/vmlinuz-3.12.49-11-default root=/dev/sda2 ${extra_cmdline} resume=/dev/sda1 splash=silent quiet showopts

  • Följande rad kommer från GRUB-filen /boot/grub/menu.lst:

    kernel /boot/vmlinuz-3.0.101-63-default root=/dev/sda2 resume=/dev/sda1 splash=silent crashkernel=256M-:128M showopts vga=0x314

Kommentar

GRUB-raderna innehåller faktiska enhetsnamn för parametrarnas rot och återuppta i stället för UUID.

Så här åtgärdar du

Enhetsnamnen bör ersättas med motsvarande UUID.

  1. Hitta enhetens UUID genom att köra kommandot blkid \<device name>.

    Till exempel:

    blkid /dev/sda1
    /dev/sda1: UUID="6f614b44-433b-431b-9ca1-4dd2f6f74f6b" TYPE="swap"
    blkid /dev/sda2
    /dev/sda2: UUID="62927e85-f7ba-40bc-9993-cc1feeb191e4" TYPE="ext3"
    
  2. Ersätt nu enhetsnamnet med dess UUID i formatet som root=UUID=\<UUID>. Om vi till exempel ersätter enhetsnamnen med UUID för rot- och återuppta-parametern som nämns i filerna /boot/grub2/grub.cfg, /boot/grub2/grub.cfg eller /etc/default/grub så ser raderna i filerna ut som följande rad:

    kernel /boot/vmlinuz-3.0.101-63-default root=UUID=62927e85-f7ba-40bc-9993-cc1feeb191e4 resume=UUID=6f614b44-433b-431b-9ca1-4dd2f6f74f6b splash=silent crashkernel=256M-:128M showopts vga=0x314

  3. Starta om skyddet.

Installera tjänsten Mobility slutförd med varning om omstart (ErrorID: 95265 & 95266)

Site Recovery tjänsten Mobility har många komponenter, varav en kallas filterdrivrutin. Filterdrivrutinen läses bara in i systemminnet under en systemomstart. Filterdrivrutinskorrigeringar kan bara realiseras när en ny filterdrivrutin läses in vid tidpunkten för en systemomstart.

Viktigt!

Det här är en varning och befintlig replikering fungerar även efter den nya agentuppdateringen. Du kan välja att starta om när du vill få fördelarna med ny filterdrivrutin, men om du inte startar om fortsätter den gamla filterdrivrutinen att fungera. Så efter en uppdatering utan omstart, förutom filterdrivrutinen, kommer fördelarna med andra förbättringar och korrigeringar i tjänsten Mobility realiseras. Även om det rekommenderas är det inte obligatoriskt att starta om efter varje uppgradering. Om du vill ha information om när en omstart är obligatorisk anger du avsnittet Starta om efter tjänsten Mobility uppgradering i Tjänstuppdateringar i Azure Site Recovery.

Dricks

Metodtips för schemaläggning av uppgraderingar under underhållsperioden finns i Support för de senaste operativsystemet/kernel-uppdateringarna i Tjänstuppdateringar i Azure Site Recovery.

LVM-stöd från version 9.20

Innan 9.20-versionen hade Logisk volymhanterare (LVM) endast stöd för datadiskar. Partitionen /boot ska finnas på en diskpartition och inte på en LVM-volym.

Från och med 9.20-versionen stöds OS-disken på LVM .

Otillräckligt utrymme (ErrorID: 95524)

När mobilitetsagenten kopieras till källdatorn krävs minst 100 MB ledigt utrymme. Kontrollera att källdatorn har den mängd ledigt utrymme som krävs och försök utföra åtgärden igen.

Låga systemresurser

De möjliga fel-ID:t som visas för det här problemet är 95572 och 95573. Det här problemet uppstår när systemet har lite ledigt minne och inte kan allokera minne för installation av mobilitetstjänsten. Se till att tillräckligt med minne har frigjorts för att installationen ska kunna fortsätta och slutföras.

VSS-installationsfel

Installationen av Volume Shadow Copy Service (VSS) är en del av installationen av Mobilitetsagenten. Den här tjänsten används i processen för att generera program konsekventa återställningspunkter. Fel under VSS-installationen kan inträffa på grund av flera orsaker. Information om de exakta felen finns i C:\ProgramData\ASRSetupLogs\ASRUnifiedAgentInstaller.log. Några av de vanliga felen och lösningsstegen är markerade i följande avsnitt.

VSS-fel -2147023170 [0x800706BE] – slutkod 511

Det här problemet uppstår oftast när antivirusprogram blockerar driften av Azure Site Recovery-tjänster.

Lös problemet så här:

  1. Granska listan över mappundantag från antivirusprogrammet.
  2. Följ de riktlinjer som publicerats av antivirusleverantören för att avblockera registreringen av DLL i Windows.

VSS-fel 7 [0x7] – slutkod 511

Det här felet är ett körningsfel som orsakas eftersom det inte finns tillräckligt med minne för att installera VSS. Öka diskutrymmet för att slutföra åtgärden.

VSS-fel -2147023824 [0x80070430] – slutkod 517

Det här felet uppstår när VSS-providertjänsten för Azure Site Recovery har markerats för borttagning. Försök att installera VSS manuellt på källdatorn genom att köra följande kommando:

"C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

VSS-fel -2147023841 [0x8007041F] – slutkod 512

Det här felet uppstår när vss-tjänstdatabasen för Azure Site Recovery VSS-providern är låst. Försök att installera VSS manuellt på källdatorn genom att köra följande kommando från en kommandotolk:

"C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

När det uppstår ett fel kontrollerar du om något antivirusprogram eller andra tjänster har fastnat i ett starttillstånd . En process i ett starttillstånd kan behålla låset på databastjänster. Det leder till fel vid installation av VSS-providern. Kontrollera att ingen tjänst är i starttillstånd och försök sedan utföra ovanstående åtgärd igen.

VSS-slutkod 806

Det här felet uppstår när användarkontot som används för installationen inte har behörighet att köra CSScript kommandot. Ange nödvändiga behörigheter för användarkontot för att köra skriptet och försöka utföra åtgärden igen.

Andra VSS-fel

Försök att installera VSS-providertjänsten manuellt på källdatorn genom att köra följande kommando från en kommandotolk:

"C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

VSS-fel – 0x8004E00F

Det här felet inträffar vanligtvis under installationen av Mobilitetsagenten på grund av problem i DCOM och DCOM är i ett kritiskt tillstånd.

Använd följande procedur för att fastställa orsaken till felet.

Granska installationsloggarna

  1. Öppna installationsloggen på C:\ProgramData\ASRSetupLogs\ASRUnifiedAgentInstaller.log.

  2. Förekomsten av följande fel indikerar det här problemet:

    Unregistering the existing application...
    Create the catalogue object
    Get the collection of Applications
    
    ERROR:
    
    - Error code: -2147164145 [0x8004E00F]
    - Exit code: 802
    

Så här löser du problemet:

Kontakta Microsoft Windows-plattformsteamet för att få hjälp med att lösa DCOM-problemet.

När DCOM-problemet har lösts installerar du om VSS-providern för Azure Site Recovery manuellt med hjälp av följande kommando från en kommandotolk:

"C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

Om programkonsekvensen inte är kritisk för dina krav på haveriberedskap kan du kringgå VSS-providerns installation.

Så här kringgår du vss-providerinstallationen för Azure Site Recovery och installerar VSS-providern för Azure Site Recovery manuellt efter installationen:

  1. Installera tjänsten Mobility. Installationen misslyckas i steget: Efter installationens konfiguration.

  2. Så här kringgår du VSS-installationen:

    1. Öppna installationskatalogen för Azure Site Recovery Mobility Service på:

      C:\Program Files (x86)\Microsoft Azure Site Recovery\agent

    2. Ändra installationsskripten för Azure Site Recovery VSS-providern InMageVSSProvider_Install och InMageVSSProvider_Uninstall.cmd så att de alltid lyckas genom att lägga till följande rader:

      rem @echo off
      setlocal
      exit /B 0
      
  3. Utför en manuell installation av Mobilitetsagenten.

  4. När installationen har slutförts och flyttas till nästa steg, Konfigurera, tar du bort de rader som du har lagt till.

  5. Om du vill installera VSS-providern öppnar du en kommandotolk som administratör och kör följande kommando:

    "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

  6. Kontrollera att VSS-providern för Azure Site Recovery är installerad som en tjänst i Windows Services. Öppna MMC för komponenttjänsten för att bekräfta att VSS-providern visas.

  7. Om installationen av VSS-providern fortsätter att misslyckas kan du arbeta med teknisk support för att lösa behörighetsfelen i kryptografiskt programprogramprogramgränssnitt (CAPI2).

INSTALLATIONEN av VSS-providern misslyckas eftersom klustertjänsten är aktiverad på en dator som inte är en klusterdator

Det här problemet gör att installationen av Azure Site Recovery Mobility Agent misslyckas under installationen av Azure Site Recovery VSS-providern. Felet beror på att det finns ett problem med COM+ som förhindrar vss-providerinstallationen.

Så här identifierar du problemet

I loggen som finns på konfigurationsservern på C:\ProgramData\ASRSetupLogs\UploadedLogs<date-time>UA_InstallLogFile.log hittar du följande undantag:

COM+ was unable to talk to the Microsoft Distributed Transaction Coordinator (Exception from HRESULT: 0x8004E00F)

Så här löser du problemet:

  1. Kontrollera att den här datorn är en dator som inte är en klusterdator och att klusterkomponenterna inte används.
  2. Om komponenterna inte används tar du bort klusterkomponenterna från datorn.

Drivrutiner saknas på källservern

Om installationen av Mobilitetsagenten misslyckas undersöker du loggarna under C:\ProgramData\ASRSetupLogs för att avgöra om några av de nödvändiga drivrutinerna saknas i vissa kontrolluppsättningar.

Så här löser du problemet:

  1. Öppna registret med hjälp av en registereditor, till exempel regedit.msc.

  2. HKEY_LOCAL_MACHINE\SYSTEM Öppna noden.

  3. SYSTEM Leta upp kontrolluppsättningarna i noden.

  4. Öppna varje kontrolluppsättning och kontrollera att följande Windows-drivrutiner finns:

    • Atapi
    • Vmbus
    • Storflt
    • Storvsc
    • Intelide
  5. Installera om eventuella saknade drivrutiner.

Nästa steg

Läs mer om hur du konfigurerar haveriberedskap för virtuella VMware-datorer.